Backdoor no WordPress é um trecho de código malicioso plantado em arquivos do site, geralmente em /wp-content/uploads, temas ou plugins, que garante acesso remoto persistente ao atacante mesmo depois que a vulnerabilidade original é corrigida. É o mecanismo que transforma uma invasão pontual em reinfecção crônica.

Se você acabou de limpar um site WordPress hackeado e ele voltou a ser comprometido em poucos dias, você não fez nada de errado na parte visível. O problema é que a porta continuou aberta. A infecção que reaparece quase sempre é sintoma de um backdoor esquecido em uma tarefa agendada, no banco de dados ou em um arquivo PHP escondido em uma subpasta de uploads.
Aqui na Apiki, lidamos com esse cenário todos os meses em sites de médio e grande porte, com múltiplos editores publicando e plugins entrando e saindo a cada sprint. Neste guia, vamos direto ao ponto: como identificar, localizar, remover e prevenir backdoors no WordPress sem transformar você em analista de malware.
O que é um backdoor no WordPress?
Um backdoor é o componente de persistência de um ataque. O invasor explora uma falha, ganha acesso e, antes de qualquer outra ação, planta um arquivo ou registro que garante o retorno. Por isso remover apenas o defacement ou o spam visível raramente resolve. Enquanto o backdoor no WordPress permanecer, a reinfecção é questão de dias.
Pense nele como uma chave reserva copiada sem o seu conhecimento. Você pode trocar a fechadura da porta da frente (corrigir o plugin vulnerável), mas se a chave reserva continua na mão do atacante, ele entra de novo pela porta dos fundos.
O WordPress é alvo preferencial por um motivo direto: escala. Ele responde por mais de 43% de todos os sites da web, segundo o share de uso do WordPress medido pelo W3Techs. Quanto maior a base, maior o incentivo para automatizar ataques contra os plugins e temas mais populares.
Por que backdoors reinfectam sites WordPress mesmo após limpeza?
A reinfecção acontece porque a limpeza tratou o sintoma e não o vetor. Na esmagadora maioria dos casos, o problema não está no core do WordPress. Está em plugins e temas desatualizados. Segundo o relatório anual de vulnerabilidades do Patchstack, em 2023 cerca de 97% das vulnerabilidades reportadas no ecossistema WordPress vieram de plugins, não do núcleo da aplicação.
O ciclo que leva à reinfecção costuma seguir três etapas:
- Vulnerabilidade pública: uma falha de upload arbitrário ou injeção em plugin é divulgada e entra em bancos de CVE que atacantes consultam diariamente.
- Varredura automatizada: bots escaneiam a web em busca de sites rodando a versão vulnerável, sem qualquer ação manual do atacante. A inteligência de ameaças da Wordfence registra bilhões de tentativas de ataque contra sites WordPress a cada mês.
- Exploração e persistência: a falha é explorada, um shell PHP é gravado em
wp-content/uploads, usuários administradores fantasmas são criados e uma tarefa agendada maliciosa é registrada para reinstalar tudo caso os arquivos sejam apagados.
A conclusão prática é incômoda: se você removeu o arquivo malicioso mas não fechou o vetor original nem revisou o banco de dados e o cron, você limpou metade do problema. O outro lado é justamente o que reabre a porta.
Quais são os sinais de que seu site WordPress tem um backdoor?
Um site WordPress comprometido nem sempre mostra sinais óbvios na página inicial. Estes são os indícios mais confiáveis de que existe um backdoor ativo:
- Usuários administradores desconhecidos: contas com privilégio de admin que ninguém da equipe criou, muitas vezes com nomes aleatórios ou e-mails de domínios estranhos.
- Arquivos PHP dentro de uploads: a pasta
wp-content/uploadsdeveria conter apenas mídia. Qualquer arquivo.phpali é fortemente suspeito e merece inspeção imediata. - Picos de requisições nos logs de acesso: chamadas repetidas para um mesmo arquivo PHP estranho dentro de uploads indicam um shell PHP sendo usado ativamente.
- Modificações recentes em arquivos do core: arquivos do WordPress alterados sem que tenha havido atualização ou deploy conhecido pela equipe.
- Redirecionamentos para domínios externos: visitantes caindo em páginas de spam, cassino ou farmácia falsa que você nunca configurou, às vezes só quando chegam via Google.
- Alertas de segurança do Google: avisos em Problemas de segurança no Search Console indicando malware. Vale consultar as orientações do Google sobre sites comprometidos para entender o impacto na indexação.
Onde os backdoors se escondem no WordPress?
Conhecer os esconderijos acelera muito a remoção. Estes são os cinco locais mais comuns em que encontramos backdoors em sites WordPress comprometidos.
Arquivos PHP isolados em wp-content/uploads
É o vetor clássico. O diretório de uploads guarda imagens e documentos, nunca código executável. Quando um plugin com upload vulnerável é explorado, o atacante grava ali um shell PHP com nomes como 1.php, php5.php, single_x1.php4 ou strings aleatórias. Preste atenção às subpastas de ano e mês, onde esses arquivos se camuflam entre milhares de mídias legítimas.
Injeção no topo de arquivos de temas e plugins
Aqui o backdoor não é um arquivo novo. É uma linha injetada no início de um arquivo legítimo. O código costuma ser ofuscado e usa a função eval() do PHP combinada com base64_decode e gzinflate. Um payload típico tem a forma eval(gzinflate(base64_decode('...')));, onde a string codificada esconde o comando real executado a cada requisição da página.
Modificações em wp-config.php e .htaccess
O wp-config.php é executado em toda requisição, o que o torna alvo ideal para persistência. Um wp-config.php infectado pode conter linhas de eval ou includes de arquivos remotos. Já o .htaccess costuma ser usado para forçar redirecionamentos ou liberar a execução de arquivos PHP que deveriam estar bloqueados no diretório de uploads.
Usuários administradores fantasmas no banco de dados
Mesmo sem nenhum arquivo malicioso, um usuário admin criado diretamente na tabela wp_users mantém o acesso. Ele não aparece em varreduras de arquivos e sobrevive a qualquer reinstalação de core. Por isso a revisão do banco de dados é parte obrigatória da limpeza, e não um passo opcional.
Tarefas agendadas maliciosas no wp_cron
Backdoors avançados se registram como tarefas agendadas. Mesmo que você apague o arquivo malicioso, o cron recria o shell no próximo agendamento. Esse é um dos principais motivos de reinfecção após limpezas superficiais e o item que mais gente esquece de checar.
Como remover um backdoor do WordPress passo a passo?
Antes de tudo, gere um backup do estado infectado para análise forense e trabalhe com calma. Apagar às cegas costuma quebrar o site sem eliminar a origem. A remoção do backdoor no WordPress segue esta ordem:
- Liste os arquivos PHP em uploads. Via terminal, rode
find wp-content/uploads -name "*.php*" -print. O padrão*.php*também captura extensões como.php4e.php5. - Exclua os arquivos confirmados como maliciosos. Após inspecionar, remova com
find wp-content/uploads -name "*.php*" -delete. Confirme antes: uploads não deveria ter nenhum PHP legítimo. - Busque funções suspeitas no código. Use
grep -r "base64_decode" wp-content/egrep -r "gzinflate" wp-content/para encontrar injeções ofuscadas em temas e plugins. - Verifique a integridade do core com WP-CLI. O comando
wp core verify-checksumscompara seus arquivos com os oficiais do WordPress.org e aponta qualquer alteração no núcleo. - Cheque as tarefas agendadas. Rode
wp cron event liste procure por eventos com hooks estranhos ou callbacks desconhecidos. Esse passo evita a reinfecção viawp_cron. - Reinstale core, plugins e temas a partir da fonte oficial. Não confie em arquivos potencialmente comprometidos. Baixe tudo novamente do repositório oficial ou do fornecedor legítimo.
- Rotacione os SALTs no wp-config.php. Gere novas chaves para invalidar todas as sessões ativas, inclusive as do atacante.
- Resete a senha de todos os usuários. Force a redefinição para garantir que credenciais vazadas deixem de funcionar imediatamente.
- Revise os usuários no banco de dados. Remova qualquer administrador fantasma e confirme que a tabela
wp_userssó contém contas legítimas.
Depois de tudo isso, só considere o site limpo quando o vetor original (o plugin ou tema vulnerável) estiver atualizado ou removido. Sem fechar essa porta, os passos acima apenas ganham tempo.
Limpeza manual, plugin de segurança ou hospedagem gerenciada: qual escolher?
Existe mais de uma forma de responder a um backdoor no WordPress, e cada uma tem um custo e uma taxa de reinfecção diferentes. A escolha depende do tamanho do site, da criticidade e de quanto risco de recaída você tolera. A tabela abaixo resume o que observamos na prática.
| Abordagem | Tempo médio de remediação | Reinfecção em 30 dias | Custo estimado (site mid-market) |
|---|---|---|---|
| Limpeza manual sem hardening | 6-12 horas | 40-60% (backdoor esquecido em wp_cron ou banco) | R$ 1.500-4.000 (consultor pontual) |
| Plugin de segurança (Wordfence ou Sucuri free) | 2-4 horas de scan e revisão | 20-35% (não bloqueia o vetor original) | R$ 0-500/mês |
| Hospedagem gerenciada com WAF e monitoramento de integridade | 30 min a 2h (incidente contido antes de escalar) | Abaixo de 5% (bloqueio no perímetro e patches virtuais) | R$ 800-3.500/mês (inclui infraestrutura) |
Dados de tempo e reinfecção baseados em benchmark de projetos corporativos da Apiki em atendimentos a sites WordPress comprometidos entre 2022 e 2024. Os custos são estimativas de mercado.
A leitura é simples. A limpeza manual isolada é a mais barata no curto prazo, mas tem a maior chance de recaída porque depende de o operador não esquecer nenhum esconderijo. Um plugin de segurança ajuda a detectar, mas não fecha o vetor no servidor. A hospedagem gerenciada com WAF é a única que ataca o problema no perímetro, antes de o backdoor ser plantado.
Como prevenir novos backdoors no WordPress?
Remover é metade do trabalho. Prevenir reinfecção exige duas camadas: aplicação e servidor. É aqui que a maioria dos tutoriais para no meio do caminho. Use o checklist abaixo como base do seu processo de hardening.
- Mantenha core, plugins e temas atualizados: ative atualizações automáticas de segurança e revise semanalmente o que está desatualizado. Como quase toda vulnerabilidade vem de plugins, esse é o item de maior impacto.
- Desative a edição de arquivos pelo painel: adicione
define('DISALLOW_FILE_EDIT', true);nowp-config.phppara impedir que um admin comprometido edite temas e plugins direto pelo dashboard. - Bloqueie a execução de PHP em uploads: configure regra no
.htaccessou no Nginx negando o processamento de arquivos.phpdentro dewp-content/uploads. Isso neutraliza o shell PHP mesmo que ele seja gravado. - Coloque um WAF na frente do site: um firewall de aplicação web filtra tentativas de exploração conhecidas antes de chegarem ao WordPress, inclusive com patches virtuais para CVEs recém-divulgadas.
- Ative autenticação em dois fatores (2FA): protege as contas de administrador contra credenciais vazadas, um dos principais vetores de invasão manual.
- Implemente monitoramento de integridade de arquivos: uma verificação contínua que alerta quando qualquer arquivo é modificado permite detectar a injeção de backdoor em horas, não em semanas.
Para o passo a passo completo de configuração, vale consultar o guia oficial de hardening do WordPress, que detalha permissões de arquivo e constantes de segurança recomendadas.
Perguntas frequentes sobre backdoors no WordPress
Um plugin de segurança sozinho remove backdoors?
Nem sempre. Um plugin de segurança detecta e remove muitos backdoors conhecidos por assinatura, mas tem dois pontos cegos: injeções ofuscadas novas e registros no banco de dados ou no wp_cron. Além disso, ele não fecha o vetor original no servidor. Por isso, mesmo com plugin, é preciso revisar usuários, tarefas agendadas e atualizar o plugin vulnerável que abriu a porta.
Quanto tempo leva para limpar um site WordPress infectado?
Depende da abordagem e do tamanho do site. Uma limpeza manual completa de um site mid-market costuma levar de 6 a 12 horas, segundo o benchmark de projetos corporativos da Apiki. Quando o incidente é contido por uma hospedagem gerenciada com WAF, a remediação cai para algo entre 30 minutos e 2 horas, porque boa parte do ataque é bloqueada no perímetro antes de escalar.
O Google removeu meu site do índice por malware, o que fazer?
Primeiro remova completamente o backdoor e o malware, incluindo os redirecionamentos. Só depois solicite a revisão no Google Search Console, na seção Problemas de segurança. Se você pedir a revisão antes de limpar de fato, o Google reprova e o processo demora ainda mais. As orientações do Google sobre sites comprometidos detalham cada etapa da reconsideração.
Backdoor pode voltar mesmo depois da limpeza?
Sim, e é o cenário mais comum. Um backdoor no WordPress reaparece quando a limpeza esqueceu uma cópia em outro esconderijo, geralmente uma tarefa no wp_cron ou um usuário admin fantasma, ou quando o plugin vulnerável não foi atualizado. Enquanto o vetor original estiver aberto, a varredura automatizada reencontra o site e o reinfecta em dias.
Vale a pena restaurar backup ao invés de limpar?
Vale, desde que você tenha certeza da data em que a infecção começou e que o backup seja anterior a ela. O risco é restaurar um backup que já contém o backdoor, o que apenas reinicia o ciclo. Mesmo restaurando, é obrigatório atualizar o plugin ou tema vulnerável, senão o site é comprometido de novo pelo mesmo vetor.
Trocar de hospedagem resolve o problema de backdoor?
Trocar de hospedagem não remove um backdoor que já está nos arquivos ou no banco de dados, porque ele viaja junto na migração. O que muda o jogo é migrar para uma hospedagem gerenciada com WAF e monitoramento de integridade, que reduz a chance de reinfecção porque bloqueia o vetor de ataque no perímetro. A limpeza ainda precisa ser feita antes ou durante a migração.
Conclusão
Um backdoor no WordPress não é um problema de arquivo, é um problema de processo. A limpeza superficial remove o que se vê e deixa a porta encostada. O ciclo só quebra quando você fecha o vetor original, revisa banco de dados e wp_cron, e coloca uma camada de defesa no servidor que impede a próxima gravação de shell PHP.
Se a sua equipe vive apagando incêndio e o site volta a ser comprometido a cada poucas semanas, o caminho não é contratar mais um consultor pontual. É mudar a base. Nosso serviço de WP Host entrega hospedagem WordPress gerenciada com hardening por camadas, WAF e monitoramento de integridade, contendo o incidente antes que ele escale. E o WP Care coloca um squad especializado para cuidar das atualizações e responder a incidentes, tirando essa pressão da sua TI interna. Fale com nosso time e veja como sair do ciclo de reinfecção de vez.