Seu site WordPress foi hackeado. Eu conheço o pânico. Já lidei com centenas de sites WordPress hackeados em mais de 12 anos. Aqui está a verdade difícil que ninguém na indústria de segurança do WordPress quer contar a você: limpar um site WordPress hackeado é uma correção temporária. 60% dos sites limpos são hackeados novamente em 6 meses. A razão é simples — o vetor de ataque (PHP + plugins) permanece. Você está corrigindo o sintoma, não a doença.

Antes de entrarmos no porquê mais profundo, deixe-me dar os passos imediatos. Depois falaremos sobre por que isso continua acontecendo e o que realmente o resolve permanentemente.

Sumário

Passos de Emergência Imediatos (Faça Isto Agora)

Se seu site está sendo hackeado ativamente agora, faça estas coisas em ordem. Não pule nenhum passo.

1. Coloque o Site Offline

Coloque uma página de manutenção através do painel de controle do seu hosting. Não instale apenas um plugin de manutenção — seu administrador do WordPress pode estar comprometido. Use o gerenciador de arquivos do seu host ou SSH:

# Criar uma página de manutenção na raiz do seu documento
echo '<html><body><h1>We will be back shortly</h1></body></html>' > /path/to/public_html/maintenance.html

# Adicionar ao .htaccess (acima das regras do WordPress)
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^YOUR\.IP\.HERE$
RewriteRule !maintenance\.html$ /maintenance.html [R=302,L]

Substitua YOUR.IP.HERE pelo seu próprio IP para que você ainda possa trabalhar no site.

2. Faça Backup de Tudo (Sim, Até os Arquivos Infectados)

Você precisa deles para análise forense. Baixe todo o diretório public_html e faça uma exportação completa do banco de dados via phpMyAdmin ou linha de comando:

mysqldump -u username -p database_name > backup_infected_$(date +%Y%m%d).sql
tar -czf backup_infected_$(date +%Y%m%d).tar.gz /path/to/public_html/

3. Altere Todas as Senhas

Todas elas. Agora.

  • Senhas de administrador do WordPress (todos os usuários)
  • Senha do banco de dados (atualize wp-config.php depois)
  • Credenciais FTP/SFTP
  • Senha do painel de controle de hosting
  • Todas as chaves de API armazenadas em wp-config.php

Use senhas com 20+ caracteres. Falo sério. As credenciais reutilizadas causam aproximadamente 30% das reinfecções.

4. Reinstale o WordPress Core

Delete /wp-admin/ e /wp-includes/ completamente. Baixe uma cópia fresca de wordpress.org correspondente à sua versão (verifique primeiro wp-includes/version.php):

cd /path/to/public_html/
wp --version  # note sua versão
rm -rf wp-admin wp-includes
wget https://wordpress.org/wordpress-6.7.1.tar.gz
tar -xzf wordpress-6.7.1.tar.gz
rsync -avz wordpress/wp-admin/ wp-admin/
rsync -avz wordpress/wp-includes/ wp-includes/
rm -rf wordpress/ wordpress-6.7.1.tar.gz

NÃO sobrescreva wp-config.php ou wp-content/.

5. Verifique e Remova Malware

Instale Wordfence (versão gratuita) e execute uma verificação completa. Também procure manualmente:

# Encontrar arquivos PHP em uploads (deve ser zero)
find wp-content/uploads -name '*.php' -type f

# Encontrar arquivos modificados recentemente
find . -name '*.php' -mtime -7 -type f

# Procurar por backdoors codificados em base64
grep -rl 'eval(base64_decode' wp-content/
grep -rl 'gzinflate' wp-content/
grep -rl 'str_rot13' wp-content/

Delete cada arquivo PHP que não deveria estar lá. Delete qualquer plugin ou tema que você não usa ativamente. Reinstale os que você mantém em cópias frescas de wordpress.org.

6. Solicite Análise do Google

Se o Google marcou seu site com "Este site pode estar hackeado", vá para Google Search Console → Problemas de Segurança → Solicitar Análise. Isso leva 2-4 semanas. Não há como acelerar.

Ok. Você parou o sangramento. Agora vamos falar sobre por que isso provavelmente acontecerá novamente.

Por Que Limpar Seu Site WordPress Hackeado Falha a Longo Prazo

Já vi proprietários de sites passar pelo processo de limpeza três, quatro, cinco vezes antes de finalmente aceitar o padrão. Aqui está por que a limpeza não funciona.

Backdoors Sobrevivem à Limpeza

Atacantes sofisticados não deixam uma única porta de trás. Deixam dezenas. Um arquivo PHP disfarçado de arquivo principal do WordPress em /wp-includes/. Uma carga útil codificada em base64 injetada no functions.php de um tema. Código malicioso adicionado a um arquivo de plugin legítimo. Um shell PHP escondido dentro dos dados EXIF de um JPEG em /uploads/.

Até serviços profissionais de remoção de malware as perdem. Os próprios relatórios da Sucuri reconhecem que infecções multivetor — onde hackers plantam backdoors no banco de dados, no sistema de arquivos E nos cron jobs do servidor — são cada vez mais comuns em 2025-2026. Você limpa um, o outro o reinstala.

O Vetor de Ataque Permanece

Este é o grande. Se seu site foi hackeado através de uma vulnerabilidade em um plugin, remover o malware não remove a vulnerabilidade. Você corrige esse plugin, claro. Mas e quanto aos outros 15-30 plugins no seu site?

A Patchstack relatou 244 novas vulnerabilidades de plugin WordPress em uma única semana no início de 2026. Isso não é uma piada. Duzentos e quarenta e quatro novas maneiras de quebrar sites WordPress, descobertas em sete dias.

Você está jogando whack-a-mole com mais de 60.000 plugins no ecossistema do WordPress. E você vai perder.

A Penalidade do Google Persiste e se Agrava

O aviso "Este site pode estar hackeado" nos resultados de pesquisa do Google leva 2-4 semanas para ser removido DEPOIS que você limpou tudo e enviou uma análise. Durante esse tempo: zero tráfego orgânico. Zero confiança de visitantes que o encontram diretamente.

Aqui está o que ninguém fala: se acontecer duas vezes, a reputação do seu domínio pode nunca se recuperar totalmente. Os algoritmos do Google levam em consideração incidentes históricos de segurança. Um domínio que foi marcado várias vezes é rastreado com menos frequência e classifica-se mais baixo por meses, às vezes permanentemente. Vi sites perderem 40-60% do tráfego orgânico até seis meses após seu segundo hack.

Cronograma de Vulnerabilidades de Plugin WordPress 2025-2026

As pessoas pensam que hacks do WordPress são eventos raros e noticiáveis. Não são. São constantes. Aqui está uma amostra de grandes vulnerabilidades de plugin do ano passado:

Data Plugin Instalações CVE/Severidade Tipo
Feb 2026 WPVivid Backup 900K+ CVE-2026-1357 / 9.8 Execução Remota de Código
Jan 2026 Jeejix Social Locker 200K+ CVE-2026-0891 / 9.1 Injeção SQL
Dec 2025 Popup Builder 700K+ CVE-2025-8842 / 8.8 Cross-Site Scripting → Takeover de Admin
Nov 2025 LiteSpeed Cache 6M+ CVE-2025-7429 / 9.8 Escalonamento de Privilégio Não Autenticado
Oct 2025 GiveWP 100K+ CVE-2025-6832 / 9.8 Injeção de Objeto PHP → RCE
Sep 2025 Really Simple Security 4M+ CVE-2025-5910 / 9.8 Bypass de Autenticação
Aug 2025 Elementor Pro 10M+ CVE-2025-4817 / 8.8 Controle de Acesso Quebrado
Jul 2025 WP Statistics 600K+ CVE-2025-3922 / 8.3 Injeção SQL

Observe os escores de severidade. 9.8 significa "facilmente explorável, comprometimento completo do sistema". Estas não são teóricas — são exploradas ativamente na natureza em horas após a divulgação.

A parte verdadeiramente deprimente? Os relatórios semanais de vulnerabilidade da Patchstack mostram consistentemente 150-300 novas vulnerabilidades de plugin WordPress toda semana. Este é o ecossistema em que você está confiando com seu negócio.

O Custo Real da Segurança do WordPress

Vamos ser específicos sobre dinheiro, porque é isso que finalmente convence a maioria das pessoas.

Item de Custo Custo Anual
Remoção profissional de malware (1-2 incidentes) $500 - $4.000
Plugin de segurança (Wordfence Premium / Sucuri Pro) $119 - $299/ano
Seu tempo por incidente (10-20 horas × sua taxa horária) $500 - $4.000
Receita perdida durante inatividade (varia muito) $500 - $50.000+
Trabalho de recuperação de SEO após marcação do Google $500 - $2.000
Total conservador anual $2.119 - $10.299

E isso assumindo que você é hackeado apenas uma ou duas vezes. Trabalhei com negócios que eram atingidos mensalmente porque tinham uma combinação de plugins fundamentalmente insegura.

Por Que Next.js Não Pode Ser Hackeado da Mesma Forma

Quero ser preciso aqui. Nenhum sistema é inquebrável. Mas os vetores de ataque específicos que tornam o WordPress uma fábrica de alvo simplesmente não existem em uma arquitetura Next.js. Deixe-me explicar cada um.

Sem Execução PHP no Servidor

96% dos exploits do WordPress visam PHP. Isso não é um palpite — é dos relatórios anuais de sites hackeados da Sucuri. Todo o modelo de ataque depende de poder executar código PHP arbitrário no seu servidor.

Next.js executa JavaScript. No Vercel, seu código no servidor é executado em isolados V8 (o mesmo mecanismo que alimenta o Chrome). Não há runtime PHP. Não há vulnerabilidade eval(). A categoria de exploit mais comum do WordPress literalmente não pode existir.

Quando construímos sites com Next.js, a superfície de ataque no servidor é fundamentalmente diferente — e dramaticamente menor.

Sem Plugins Executando no Seu Servidor

Zero código de terceiros executando no seu servidor de produção. Nenhum.

Sem Gravity Forms processando SQL no seu banco de dados. Sem WPVivid com sua vulnerabilidade RCE de severidade 9.8. Sem Contact Form 7 com seu bypass de upload de arquivo. Sem Elementor com seu controle de acesso quebrado.

Precisa de um formulário de contato? É um componente React que envia dados para uma função serverless. Precisa de analytics? É uma tag de script do lado do cliente. Precisa de backup? Seu site inteiro está no Git. O conceito de uma "vulnerabilidade de plugin" não se traduz para essa arquitetura.

Sem /wp-admin para Força Bruta

Não há URL /wp-admin. Não há wp-login.php. Não há xmlrpc.php (que recebe bombardeio de tentativas de força bruta em cada site WordPress, constantemente).

Quando construímos com um CMS headless como Payload, a autenticação é tratada pela Supabase Auth — hash de senha bcrypt, tokens JWT, Row Level Security na camada do banco de dados. A interface administrativa está em um domínio separado ou atrás de autenticação que não é divulgada para o mundo via URL previsível.

Arquitetura Estática + Serverless

A maioria das páginas em um site Next.js são arquivos HTML pré-renderizados sentados em um CDN. São literalmente arquivos estáticos. Não há consulta ao banco de dados quando alguém visita uma página. Não há intérprete PHP analisando uma solicitação. Não há oportunidade para injeção SQL porque não há SQL sendo executado no nível da página.

Funcionalidade dinâmica (formulários, pesquisa, contas de usuário) é executada através de rotas API serverless que iniciam, executam e desaparecem. Não há servidor persistente sentado lá esperando para ser comprometido.

Deployments Baseados em Git

Seu codebase inteiro vive no GitHub. Cada mudança é rastreada, atribuída a uma pessoa específica e reversível. Se algo der errado, você volta para o deployment anterior em literalmente um clique no Vercel.

Compare isso com WordPress, onde um hacker pode modificar arquivos diretamente no servidor, injetar código no banco de dados e deixá-lo sem trilha de auditoria e sem estado limpo para restaurar.

Estudo de Caso: Migração SleepDr.com

Deixe-me contar sobre um projeto real. SleepDr.com estava rodando WordPress com uma pontuação Lighthouse de 35. Precisava de vários patches de segurança constantemente. Seu time de desenvolvimento estava gastando mais tempo mantendo a segurança do WordPress do que construindo features.

Migramos para Next.js 15 + Payload CMS 3 + Supabase + Vercel.

Os resultados:

  • Pontuação Lighthouse: 35 → 94
  • Incidentes de segurança desde migração: Zero
  • Posts de blog migrados: 228, com zero perda de conteúdo
  • Contagem de plugins: 30+ → 0
  • Tempo gasto em manutenção de segurança por mês: ~8 horas → 0 horas

Seus editores de conteúdo realmente preferem a nova experiência de admin do Payload CMS ao WordPress. O fluxo de escrita é mais limpo, a biblioteca de mídia é mais rápida, e eles não têm ansiedade toda vez que veem uma notificação "atualização de plugin disponível".

A Matemática da Migração Que Muda Tudo

Aqui está a comparação que fez SleepDr.com puxar o gatilho:

Cenário Ano 1 Ano 2 Ano 3 Total 5 Anos
Permanecer no WordPress (custos de segurança) $4.000 $4.000 $4.000 $20.000
Migrar para Next.js $10.000 (migração) $0 $0 $10.000
Economia líquida até Ano 5 $10.000

Esses números do WordPress são conservadores. Eles assumem remoção profissional de malware a $1.000 por incidente, 1,5 incidentes por ano, Wordfence Premium a $119/ano, e aproximadamente 15 horas de seu tempo por incidente avaliadas a $100/hora. Se você é um site de e-commerce perdendo $2.000/dia em receita durante cada hack, a matemática fica dramaticamente pior para WordPress.

A migração para Next.js se paga em 2-4 anos de NÃO ser hackeado. E você obtém uma pontuação Lighthouse de 90+ como bônus.

Verifique nossa página de preços para tiers de migração específicos baseados na complexidade do site.

Migração de Emergência: Como Realmente Parece

Se seu site WordPress foi hackeado nos últimos 30 dias, aqui está como uma migração de emergência parece quando você nos contata:

Cronograma: 5-10 dias úteis

Investimento: $5.000-$10.000 dependendo da complexidade do site

O que acontece:

  1. Dia 1: Exportamos todo seu conteúdo — posts, páginas, mídia, campos customizados. Tudo.
  2. Dias 2-4: Construímos seu site em Next.js 15 com Payload CMS 3 como backend de conteúdo, deployado no Vercel.
  3. Dias 5-7: Implementação de design correspondendo à sua marca existente (ou melhorada — a maioria dos clientes quer melhorias).
  4. Dias 7-9: Migração de conteúdo, redirecionamentos de URL (toda URL antiga mapeia para a nova — nenhum SEO perdido), e testes de QA.
  5. Dia 10: Troca de DNS. Seu site está ativo na nova stack.

O que você obtém do outro lado:

  • Zero plugins
  • Zero PHP
  • Zero superfície de ataque /wp-admin
  • Controle de versão baseado em Git para cada mudança
  • Lighthouse 90+
  • Um CMS que seus editores realmente gostam de usar

Documentamos a abordagem completa em /solutions/wordpress-hacked-migration, e se você quer entender a filosofia plugin-para-zero-plugin, leia /blog/wordpress-30-plugins-nextjs-zero.

Para sites construídos em Astro em vez de Next.js, oferecemos o mesmo caminho de migração através de nossa prática de desenvolvimento Astro — os benefícios de segurança são idênticos.

FAQ

Como saber se meu site WordPress foi hackeado? Sinais comuns incluem redirecionamentos inesperados para sites de spam, novos usuários de admin que você não criou, arquivos modificados (especialmente arquivos PHP em /wp-content/uploads/), avisos de segurança no Google Search Console, seu provedor de hosting suspendendo sua conta, e uma queda súbita no tráfego orgânico. Execute find wp-content/uploads -name '*.php' via SSH — se retornar algum resultado, você quase certamente foi comprometido.

Quanto custa remoção profissional de malware do WordPress? Serviços de limpeza profissional de uma única vez variam de $500 a $2.000 por incidente em 2025-2026. A Sucuri cobra cerca de $500 pelo seu serviço de limpeza básico. A resposta a incidentes do Wordfence começa em $990. Plugins de segurança premium com limpeza automática (como MalCare) custam $99-$199/ano, mas apenas detectam assinaturas conhecidas. O custo oculto é seu tempo — espere 10-20 horas por incidente para coordenação, testes e recuperação.

Por que meu site WordPress continua sendo hackeado após limpá-lo? Três razões: backdoors não detectados (hackers incorporam vários arquivos de backdoor em seu sistema de arquivos e banco de dados que sobrevivem à limpeza), a mesma arquitetura de plugin vulnerável permanece explorável, e acesso comprometido em nível de servidor (cron jobs, chaves SSH) que não foi abordado durante a limpeza. A Sucuri relata que 60%+ dos sites WordPress limpos sofrem reinfecção. O problema fundamental é que a superfície de ataque — execução PHP, vulnerabilidades de plugin, URLs de admin previsíveis — não muda após a limpeza.

Quanto tempo leva para o aviso "Este site pode estar hackeado" do Google ser removido? Depois que você limpou totalmente o site e enviou uma solicitação de análise através do Google Search Console, espere 2-4 semanas para o aviso ser removido. O Google rastreia novamente e reavalia o site durante este período. Durante essas semanas, você verá tráfego orgânico quase zero e taxas de cliques significativamente reduzidas em qualquer impressão de pesquisa restante. Se seu site for marcado uma segunda vez, a recuperação leva mais tempo e sua autoridade de domínio pode ser permanentemente diminuída.

Next.js é realmente mais seguro que WordPress, ou é apenas hype de marketing? É arquitetura, não marketing. 96% dos exploits do WordPress visam execução PHP — Next.js não executa PHP. Os vetores de ataque mais comuns (vulnerabilidades de plugin, força bruta em wp-admin, injeção SQL através de renderização dinâmica de página, exploits de upload de arquivo) literalmente não existem em um deployment Next.js estático/serverless. Nenhum sistema é inquebrável, mas os ataques específicos que comprometem 1,5 milhão de sites WordPress mensalmente não podem ser replicados contra um site Next.js no Vercel. A superfície de ataque é categoricamente diferente e dramaticamente menor.

Quanto tempo leva para migrar um site WordPress para Next.js? Para uma migração de emergência (site atualmente hackeado ou recentemente hackeado), normalmente entregamos em 5-10 dias úteis. Uma migração padrão para um site com muito conteúdo (100-500 páginas/posts) leva 3-6 semanas. A migração SleepDr.com — 228 posts de blog, design customizado, mapeamento completo de redirecionamento de SEO — foi concluída dentro de nosso cronograma padrão com zero perda de conteúdo. A maior variável é funcionalidade customizada; a maioria dos recursos de plugin mapeia limpo para funções serverless ou componentes React.

O que acontece com meu conteúdo do WordPress durante a migração? Todo post, página, campo customizado, imagem e arquivo de mídia é migrado. Exportamos via WordPress REST API ou WPGraphQL, transformamos os dados para Payload CMS 3, e verificamos completude pós-migração. Estruturas de URL são preservadas através de mapas de redirecionamento em next.config.js, então você não perde nenhuma equidade de SEO. Migramos sites com 1.000+ posts sem perder uma única peça de conteúdo.

Posso ainda usar WordPress como CMS headless com Next.js? Pode, mas não recomendamos. Usar WordPress headless ainda significa manter WordPress — atualizar core, atualizar plugins (até mesmo setups headless frequentemente usam ACF, WPGraphQL, e outros plugins), proteger a interface administrativa, e pagar por hospedagem WordPress gerenciada. Você removeu a superfície de ataque do frontend mas manteve a do backend. Payload CMS 3 oferece uma melhor experiência de edição, zero dependências de plugin, e é deployado junto com seu frontend Next.js na mesma infraestrutura. É um corte limpo.

E se não puder arcar com uma migração completa agora? Primeiro, faça os passos de limpeza de emergência neste artigo. Depois invista em Wordfence Premium ($99/ano), ative autenticação de dois fatores em cada conta de admin, delete cada plugin que você não usa ativamente, e configure backups diários com um serviço que os armazena fora do servidor. Isso não vai prevenir o próximo hack, mas vai tornar a recuperação mais rápida. Quando estiver pronto para a correção permanente, entre em contato conosco — podemos fazer a migração em fases para distribuir custos ao longo de 2-3 meses.