Meu WordPress foi hackeado três vezes. O que eu aprendi sobre segurança
Eu tenho empresa de tecnologia, data center próprio e suporte olhando tudo o dia inteiro. Mesmo assim tive três sites em WordPress invadidos: um por plugin em auto update, um por template pago descontinuado e um pelo Elementor. Aqui eu conto como cada um foi descoberto e o que eu faço diferente hoje.
🎧 PREFERE OUVIR? · 17 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 17 minutos no canal @josimarjmv em 12 de junho de 2026, direto, com corte só no começo e no fim. Assista e leia junto. Aqui embaixo eu conto as três invasões por escrito, na ordem, e ponho o que eu fui conferir depois: a definição de menor privilégio do NIST, o guia de segurança do próprio WordPress, os números da Patchstack e o que o Google chama de conteúdo invadido.
eu tive três sites em WordPress invadidos, e nenhum foi por senha fraca. O primeiro veio por um plugin atualizado sozinho, o segundo por um template pago que foi descontinuado e o terceiro pelo Elementor, num site que ficou dois, três meses sem monitoramento. Nas três vezes restaurar o backup não resolveu: em dois, três dias a invasão voltava. O que eu aprendi é que WordPress vira um ponto único de falha cheio de código de terceiro, e que hoje eu não recomendo ele pra site nem pra landing page.
De onde eu falo
Vou dar minha carteirada antes. Eu sou CEO de uma empresa de tecnologia, cuido de time de desenvolvimento, front, back, infra e mobile, e boto a mão na massa: infraestrutura pesada, CDN no Brasil e nos Estados Unidos pra entrega de vídeo. A gente tem data center próprio, aqui e em Miami. O que eu trago são coisas que aconteceram comigo em mais de 20 anos de tentativa, acerto e erro.
Quem tem ambiente próprio fica meio bitolado com segurança. Eu falo que eu sou cagão: a gente controla tudo, fecha tudo, cerca tudo, porque é atacado o tempo inteiro. E mesmo assim eu fui hackeado pelo WordPress. Não uma vez. Três.
Então não leia isso como história de quem deixou a porta aberta por desleixo. Tem gente mexendo o dia inteiro na minha empresa, cliente chegando, suporte olhando, dev do lado. Aconteceu assim mesmo.
A lei do menor privilégio e o ponto único de falha
Tem uma regra que a gente usa muito: a lei do menor privilégio. Um select de banco de dados é select. Então pra que você vai dar permissão de insert pra quem só faz select? Agora me conta: quantos desenvolvedores você conhece que criaram um usuário pra select no banco e outro pra insert? É coisa de ambiente de produção, de quando tem compliance, mas é prática altamente recomendada pra qualquer coisa séria.
Fui conferir a definição formal depois de gravar. O glossário do NIST descreve o menor privilégio como o princípio de restringir o acesso de usuários e processos ao mínimo necessário pra cumprir a tarefa. E o guia de hardening do próprio WordPress aplica isso ao banco: pra operação normal, o usuário do MySQL só precisa de SELECT, INSERT, UPDATE e DELETE, e o resto pode ser revogado.
Essa lei bate de frente com outra coisa: o ponto único de falha. Quando todo mundo usa a mesma coisa, e ela é pública, tem gente do bem usando e gente nem tão do bem assim estudando como funciona. Descobrem o ponto fraco e às vezes nem é pra te atingir. Te atinge de tabela. Eu já contei o lado de quem depende de um serviço só quando o GitHub caiu pela terceira vez.
No WordPress o plugin é público. Qualquer pessoa pega um plugin muito usado, gratuito ou pago, ou um template, abre, vê as falhas e faz engenharia reversa. Dá até pra criar um plugin bacana só pra injetar maldade depois.
E na esmagadora maioria das vezes não é pra te prejudicar. É pra usar o que é seu:
- Ransomware, que sequestra o que estiver no servidor.
- Botnet: espalham malware em servidor mal configurado pra juntar máquina.
- Proxy residencial: a botnet vira proxy usando a sua máquina. Você que compra proxy residencial pra fazer scraping sem ser barrado, cuidado. Quem você conhece que assinou contrato pra emprestar a própria conexão?
- Link escondido pra SEO, que foi o que fizeram comigo duas vezes.
Quem usa WordPress e quem ataca WordPress
O WordPress é aberto, é open source. Você abre o código-fonte inteiro e entende como funciona. E quem usa WordPress, em geral, é quem não é técnico. Ele foi feito pra designer, pra agência, pra quem está na abstração da programação: arrasta, solta, clica, digita, e está pronto o blog, o site, a landing page.
Então de um lado você tem gente que não entende de programação montando o site. Do outro, o cara maldoso que entende, e que faz engenharia reversa pra achar a falha. Soma a isso uma loja de plugins feitos por sabe-se lá quem, avaliados por sabe-se lá quem. Tantas estrelas no WordPress.org, ok. Nada impede que o dono de um plugin que está bombando solte uma maldade na próxima versão, pra milhões de pessoas que deixaram a atualização automática ligada.
Na gravação eu falei em milhares, senão milhões de plugins, e admiti que não sabia o número. Fui olhar: em 09/10/2026 o diretório oficial anuncia mais de 74 mil plugins gratuitos. E o relatório da Patchstack sobre 2024 contou 7.966 vulnerabilidades novas no ecossistema naquele ano: 96% em plugins, 4% em temas e só sete no núcleo do WordPress. O mesmo relatório diz que 1.614 plugins e temas foram removidos do repositório por falha de segurança sem correção.
Ou seja: o problema quase nunca é o WordPress em si. É o que você pendura nele. E a gente sabe que WordPress, pra funcionar em produção, precisa de um monte de plugin.
Primeira invasão: o plugin que se atualizou sozinho
Foi há uns quatro, cinco anos, na época da pandemia. Um site nosso estava com auto update ligado e tinha uns plugins instalados, aquela coisarada toda. Um deles foi atualizado, e na atualização veio um vírus.
Esse vírus tomava conta do template, desativava o nosso plugin de segurança de login, criava um usuário pra ele e começava a fazer postagem com link de SEO. Uma bagunça.
Como a gente descobriu? Apareceu lá um usuário que ninguém tinha criado. A gente restaurava o backup, voltava, e em um, dois, três dias o usuário estava lá de novo, com um tanto de coisa de novo.
Até que fomos fazer o checklist completo, na mão, porque nessa época não tinha IA pra ajudar:
- O que foi instalado recentemente? Nada.
- O que foi atualizado recentemente? Tal coisa.
- Desativa tudo.
- Começa a olhar código, plugin por plugin.
Foram dois, três dias pra encontrar onde era, porque é um monte de plugin. Achamos o maldito, tiramos e ficou tudo bem.
Um detalhe que eu não escondo: quem fazia o site naquela época não tinha tanto conhecimento de segurança. O caminho normal na minha empresa, antes da IA, era a pessoa entrar pelo suporte, ir pra desenvolver site, passar pra uma aplicação um pouco mais complicada e ir subindo a escadinha. Botar um site em produção é requisito básico pra quem quer aprender a programar. Só que o site do iniciante estava exposto pro mundo como qualquer outro.
Segunda invasão: o template pago que a empresa abandonou
Essa foi no site da nossa plataforma de vídeo. A gente comprou um template pago. Uns 70, se eu não me engano, e pra mim template de 70 é caro pra caramba. Custei a pagar. Mas a equipe me convenceu: ia demorar muito fazer um do zero, o template era bonito e tinha uma performance razoável com todos os plugins necessários.
Funcionou uma beleza. Um ano, dois anos, três anos. Acho que foi no quarto ano que o template foi descontinuado. A empresa sumiu e parou de dar atualização. No meio disso o WordPress deu aquela reviravolta do Gutenberg, o editor em blocos que entrou no WordPress 5.0, em dezembro de 2018.
De alguma forma esse template foi infectado. Lá vamos nós de novo. Dessa vez começou a aparecer link interno pra pornografia e pra cassino online. Isso é um perigo: pro usuário final não aparece, fica escondidinho, mas te arrebenta no SEO. É até tática black hat que o povo usa pra sacanear concorrente.
O Google tem nome pra isso. Nas políticas de spam da Pesquisa é "conteúdo invadido", e um dos exemplos é exatamente a injeção de texto ou link oculto que o buscador enxerga e você e o visitante têm dificuldade de achar.
Esse era mais esperto, não era escancarado igual ao outro. Foi alguém do nosso suporte que viu. Primeira coisa: restaura o backup. Passou dois, três dias, apareceu de novo.
E é engraçado: parece que eles gostam de trabalhar no fim de semana. Deu sexta-feira às seis da tarde, os monstrinhos estão todos soltos. Chega segunda, batata, está lá o site avacalhado de novo. O meu suporte funciona sexta, sábado e domingo direto, então é brincadeira, mas é brincadeira com fundo de verdade.
A primeira desconfiança é sempre plugin. Desativa tudo, testa. Dessa vez foi mais difícil, porque não era plugin: era o template. Ele tinha sido descontinuado, mas tinha uma atualização pendente disponível. Em algum momento alguém aplicou.
E aí vem a parte que mais me marcou. Ficou igual doença: incubado. A atualização tinha acontecido três meses antes. Quando a gente descobriu, já estava infiltrado no blog e em um monte de coisa.
Agora pensa na trabalheira. Ou você põe um band-aid no template do seu site, ou troca de template. A gente fez a terceira coisa: criou o próprio template. Resolveu esse problema.
Terceira invasão: o site que ficou sem monitoramento
Essa é de 2026. A gente está mudando os sites pra um pipeline com inteligência artificial, bem mais leve, e foi mexendo nisso que eu descobri que mais um site meu tinha sido hackeado. Ninguém tinha visto. Eu só vi por causa da migração.
Era o site de uma plataforma EAD nossa, uma landing page importante. E esse site estava sem monitoramento. A gente tem monitoramento de link, de backlink, de SEO, de H1 e H2. Tinha subido uma atualização recente e nela não subiu o monitoramento. Ficou por isso mesmo, uns dois, três meses a ver navios.
É o que joga fora o trabalho inteiro: a gente esquece o bendito do monitoramento e o trem avacalha tudo. O próprio guia de segurança do WordPress fala disso com todas as letras, que prevenção às vezes não basta e que é a detecção que te deixa reagir rápido e recuperar o site.
Nesse último, o hack estava no Elementor. A gente tinha o Elementor pago. Eu nem quis descobrir por onde entrou dessa vez, então não vou dizer que foi falha do plugin ou falha da nossa instalação. A gente já ia passar a faca no WordPress mesmo. Fizemos o site novo, transferimos o blog e passamos a faca no Elementor e no WordPress inteiro.
O que as três vezes têm em comum
Olhando as três de uma vez, o roteiro se repete.
Sobre backup, eu já escrevi separado: backup que nunca foi restaurado em teste não é backup. Aqui a lição é outra. O backup funcionava. Ele só restaurava o site junto com a invasão.
E tem o risco que não é técnico. Quando você usa coisa de terceiro, o dono faz o que quiser. Pode descontinuar, pode tirar do ar, pode começar a cobrar. Empresa privada, o negócio é dela. O template de 70 que sumiu no quarto ano é isso em tamanho pequeno.
O que eu faço hoje
Por que a gente usava WordPress, afinal? Pra agilizar. Lá no começo a gente não usava, e dependia do time de dev pra tudo. Mesmo com o builder particular que eles fizeram, toda mudança passava por desenvolvedor. O WordPress tirou esse gargalo. E trouxe os três casos que eu contei.
Hoje o site sai de um pipeline com inteligência artificial, mais automatizado e bem mais leve. Não tem plugin de terceiro rodando no servidor pra alguém fazer engenharia reversa. Eu conto o lado do mercado disso em por que eu acho que o WordPress cai até 2027.
Então, Josimar, você recomenda WordPress pra site? Não. Pra landing page? Não. Onde eu ainda vejo sentido:
- Projeto muito grande, já em produção, que dá muito trabalho refazer.
- Coisa que exige um backend de segurança e pagamento, como e-commerce.
Se você vai continuar no WordPress, o que eu tiraria das minhas três pancadas é isto:
- Tenha menos plugin, e saiba qual foi atualizado e quando.
- Template e plugin sem ninguém mantendo é pra trocar, mesmo funcionando.
- Não deixe site nenhum sem monitoramento de link e de estrutura. Foi o que faltou no meu.
- Achou usuário que ninguém criou ou link que ninguém pôs? Não pare no backup. Ache a porta.
Eu tenho empresa desde os 18 anos e já vendi site. Hoje não vendo, porque o meu negócio é vídeo e é onde eu tenho escala. Mas quem quer aprender a fazer site pra vender precisa aprender o pacote inteiro: desenvolver, subir, backup, rollback, como apresentar e como vender. É o que eu mostro, mão na massa, na Imersão de Sites.
Três sites hackeados com WordPress, numa empresa de tecnologia. Se aconteceu comigo, olha o seu hoje.
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
Por que site em WordPress é invadido com tanta frequência?
Pela soma de duas coisas. O código é aberto e muito usado, então quem quer achar falha pode ler tudo e fazer engenharia reversa. E quem monta o site, na maioria, não programa: é designer, agência, gente que está na abstração do arrasta e solta. De um lado quem não entende de código, do outro quem entende e está procurando brecha. No meio, um diretório com dezenas de milhares de plugins feitos e avaliados por gente que você não conhece.
Como eu descubro que o meu site foi invadido?
Nos meus três casos, nunca foi alarme. No primeiro apareceu um usuário que ninguém da equipe tinha criado. No segundo, alguém do suporte viu link pra pornografia e cassino online no meio do site. No terceiro eu só vi porque estava migrando o site pro pipeline novo. O que teria me avisado antes é monitoramento de link, backlink e estrutura da página, e era justamente o que faltava no site que ficou dois, três meses invadido.
Restaurar o backup resolve um WordPress hackeado?
Sozinho, não resolveu nenhuma vez comigo. A gente restaurava, o site voltava limpo e em dois, três dias o usuário estranho estava lá de novo, porque o plugin ou o template infectado voltava junto com o backup. No caso do template a atualização contaminada tinha entrado três meses antes. Backup é a primeira coisa que eu faço pra tirar a bagunça do ar, mas a invasão só para quando você acha por onde ela entrou.
Atualização automática de plugin é segura?
Ela te protege de falha conhecida e te expõe a outra coisa: se o plugin passar a trazer código malicioso, ele chega no seu site sem ninguém olhar. Foi assim a minha primeira invasão, na época da pandemia. Eu não digo pra desligar e esquecer, porque plugin desatualizado também é porta aberta. Digo pra ter menos plugin, saber qual foi atualizado e quando, e ter monitoramento pra perceber no mesmo dia se o site mudou sozinho.
Template pago é mais seguro que template gratuito?
Pagar não garantiu nada pra mim. O template do site da minha plataforma de vídeo era pago, funcionou bem por uns três anos e no quarto foi descontinuado: a empresa sumiu e parou de atualizar. Ficou uma atualização pendente, alguém aplicou e o site foi infectado. Depois disso a gente passou a fazer o próprio template. O que conta não é o preço, é se tem alguém mantendo aquilo.
O que é a lei do menor privilégio?
É dar pra cada usuário e pra cada sistema só a permissão que ele precisa pra fazer o trabalho dele. O exemplo que eu uso é o do banco de dados: se a aplicação só faz select, pra que o usuário dela tem permissão de insert? Em produção com compliance isso é prática recomendada. Num WordPress cheio de plugin, cada plugin roda com o acesso do site inteiro, e é por isso que um só infectado toma conta de tudo.
Você recomenda WordPress para site ou landing page?
Não. Nem pra site institucional, nem pra landing page. Onde eu ainda vejo sentido é em projeto muito grande, que já está em produção e daria muito trabalho refazer, ou em coisa que exige um backend de segurança e pagamento, como e-commerce. Pro site e pra landing page eu passei a faca: hoje sai de um pipeline com inteligência artificial, bem mais leve, sem plugin de terceiro rodando no servidor.
Por que alguém invade o site de uma empresa pequena?
Na esmagadora maioria das vezes não é pra te prejudicar, é pra usar o que é seu. Põem link escondido pra ganhar posição no Google com o seu domínio, instalam ransomware ou colocam a máquina numa botnet, que depois vira proxy residencial vendido por aí. Você é atingido de tabela, porque usa a mesma coisa pública que milhões de outros sites usam.
Baseado na gravação do canal @josimarjmv publicada em 12/06/2026 (16min54s), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: o data center próprio no Brasil e em Miami; a lei do menor privilégio com o exemplo do select e do insert; o ponto único de falha; ransomware, botnet e proxy residencial; a primeira invasão, na época da pandemia, pelo plugin em auto update, com o usuário criado, o plugin de segurança de login desativado e os dois, três dias pra achar; o template pago de uns 70 (eu não digo a moeda na gravação), descontinuado no quarto ano, com os links pra pornografia e cassino e os três meses de incubação; a terceira invasão, em 2026, na landing page da plataforma EAD sem monitoramento, com o problema no Elementor pago, sem investigação da causa; a recomendação de não usar WordPress pra site nem pra landing page. Os prazos são de memória.
Nota de cronologia: "este ano" e "recentemente" na gravação querem dizer o primeiro semestre de 2026.
Apuração minha (09/10/2026): a definição de menor privilégio é do glossário do NIST (CNSSI 4009-2022, SP 800-12 Rev. 1). Os privilégios mínimos do usuário do banco e o trecho sobre monitoramento e detecção estão no Hardening WordPress, do Advanced Administration Handbook. As 7.966 vulnerabilidades de 2024, a divisão de 96% em plugins e 4% em temas, as sete no núcleo e os 1.614 plugins e temas removidos são do State of WordPress Security in 2025, da Patchstack. O número de mais de 74 mil plugins gratuitos é o que o diretório do WordPress.org exibia em 09/10/2026. A data do editor em blocos é a do anúncio do WordPress 5.0 "Bebo", de 06/12/2018. A definição de conteúdo invadido e o exemplo de link oculto são das políticas de spam da Pesquisa Google.