Backdoor no WordPress é um trecho de código malicioso inserido em arquivos do site, geralmente em /wp-content/uploads, em temas ou em plugins, que concede acesso remoto persistente ao atacante mesmo depois que a falha original é corrigida. Funciona como uma chave reserva: enquanto o arquivo existir, o invasor volta quando quiser.

Se você gerencia um site WordPress em escala, com vários editores publicando e plugins entrando e saindo, sabe que a superfície de ataque cresce a cada deploy. O pior cenário não é o defacement visível. É o backdoor silencioso, que reabre a porta semanas após a limpeza, derruba a reputação do domínio no Google e ainda compromete dados. Neste artigo, mostramos como identificar, localizar, remover e, principalmente, prevenir backdoors no WordPress sem depender de tentativa e erro.
O que é um backdoor no WordPress?
Um backdoor é o mecanismo de persistência. O atacante explora uma vulnerabilidade, ganha acesso, e antes de qualquer coisa planta um arquivo que garante o retorno. Por isso limpar a infecção visível raramente resolve. Se o backdoor permanece, a reinfecção é questão de dias.
O WordPress é alvo preferencial por um motivo simples: escala. Ele responde por mais de 43% de todos os sites da web, segundo o share de uso do WordPress segundo o W3Techs. Quanto maior a base, maior o incentivo para os atacantes automatizarem ataques contra plugins e temas populares.
Por que sites WordPress são alvo de backdoors?
Na esmagadora maioria dos casos, o problema não está no core do WordPress. Está em plugins e temas desatualizados ou mal mantidos. De acordo com o relatório anual de vulnerabilidades do Patchstack, a grande maioria das vulnerabilidades reportadas no ecossistema WordPress vem de plugins, não do núcleo da aplicação.
O ciclo costuma ser este:
- Vulnerabilidade pública: uma falha de upload arbitrário ou injeção em plugin é divulgada e entra em bancos de CVE consultados por atacantes.
- Varredura automatizada: bots escaneiam a web em busca de sites rodando a versão vulnerável, sem qualquer ação manual.
- Exploração e persistência: o atacante explora a falha, planta um shell PHP em wp-content/uploads e cria usuários administradores fantasmas.
A inteligência de ameaças da Wordfence mostra que sites com plugins desatualizados concentram a maioria dos comprometimentos. Em outras palavras: o backdoor no WordPress quase sempre é a consequência de um plugin que ninguém atualizou.
Como saber se o seu site WordPress tem um backdoor?
Alguns sinais indicam que seu site WordPress pode estar hackeado, mesmo que a página inicial pareça normal:
- Usuários administradores desconhecidos: contas com privilégio de admin que ninguém da equipe criou, frequentemente com nomes aleatórios.
- Picos de tráfego inexplicados nos logs: requisições repetidas para um mesmo arquivo PHP estranho dentro de /uploads.
- Arquivos PHP no diretório de uploads: a pasta wp-content/uploads deveria conter apenas mídia. Qualquer arquivo .php ali é suspeito.
- Modificações recentes em arquivos do core: arquivos do WordPress alterados sem que houvesse atualização ou deploy.
- Redirecionamentos para domínios externos: visitantes caindo em páginas de spam ou farmácia falsa que você nunca configurou.
- Alertas no Google Search Console: avisos em “Problemas de segurança” indicando malware em WordPress detectado pelo Google.
Onde os backdoors costumam se esconder?
Conhecer os esconderijos acelera muito a remoção. Estes são os locais mais comuns.
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. Atenção às subpastas de ano e mês, onde esses arquivos se camuflam.
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 para esconder o payload. Um exemplo de payload ofuscado tem a forma eval(gzinflate(base64_decode('...')));, onde a string codificada esconde o comando real executado a cada requisição.
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. Já o .htaccess pode ser usado para forçar redirecionamentos ou liberar a execução de arquivos que deveriam estar bloqueados.
Usuários administradores fantasmas no banco de dados
Mesmo sem arquivo malicioso, um usuário admin criado pelo atacante diretamente na tabela wp_users mantém o acesso. Por isso a revisão do banco de dados é parte obrigatória da limpeza.
Tarefas agendadas maliciosas no wp_cron
Backdoors avançados se registram como tarefas agendadas. Mesmo que você apague o arquivo, o cron recria o malware no próximo agendamento. Esse é um dos principais motivos de reinfecção após limpezas superficiais.
Como remover backdoors do WordPress passo a passo?
Antes de tudo, gere um backup do estado infectado para análise forense e trabalhe com calma. A remoção segue esta ordem.
- Liste os arquivos PHP em uploads. Via terminal, rode
find wp-content/uploads -name "*.php*" -print. O*.php*também captura .php4 e .php5. - Exclua os arquivos suspeitos. Confirmados como maliciosos, remova com
find wp-content/uploads -name "*.php*" -delete. - Busque funções suspeitas no código. Use
grep -r "base64_decode" wp-content/egrep -r "gzinflate" wp-content/para encontrar injeções ofuscadas. - 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. - 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.
- Rotacione os SALTS no wp-config.php. Gere novas chaves para invalidar sessões ativas do atacante.
- Resete a senha de todos os usuários. Force a redefinição para garantir que credenciais vazadas deixem de funcionar.
- Revise os usuários no banco de dados. Remova qualquer administrador fantasma e verifique tarefas agendadas no wp_cron.
Quais ferramentas usar para escanear malware no WordPress?
Nenhuma ferramenta é infalível, mas combinar um scanner externo com um scanner em servidor aumenta a chance de detectar backdoors ofuscados. A tabela abaixo compara as opções mais relevantes hoje.
| Ferramenta | Tipo | Escaneia banco de dados | Detecção de backdoor ofuscado | Plano gratuito |
|---|---|---|---|---|
| Wordfence | Plugin WordPress | Sim | Assinatura + heurística | Sim (assinaturas com 30 dias de atraso) |
| Patchstack | Plugin + serviço | Não (foco em vulnerabilidade) | Virtual patching | Sim (alertas de CVE) |
| Sucuri SiteCheck | Scanner externo (web) | Não (apenas frontend) | Limitada (só payloads visíveis) | Sim |
| MalCare | Plugin com scan em servidor próprio | Sim | Heurística avançada | Scan gratuito; remoção paga |
| WPScan | CLI / API | Não | Não (foco em CVE de plugins/temas/core) | Sim (até 25 requisições/dia) |
Como prevenir 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.
Camada de aplicação
- Atualizações automáticas de segurança: mantenha core, plugins e temas sempre na versão corrigida, eliminando o vetor mais comum de backdoor no WordPress.
- Princípio do menor privilégio: conceda apenas o nível de acesso necessário a cada usuário, evitando administradores desnecessários.
- Autenticação em dois fatores (2FA): bloqueie ataques de força bruta no login, mesmo com senha vazada.
- Remoção de plugins e temas inativos: código que não está em uso continua sendo superfície de ataque. Apague o que não roda.
- Desabilitar o editor de arquivos: adicione
define( 'DISALLOW_FILE_EDIT', true );ao wp-config.php para impedir edição de código pelo painel caso um admin seja comprometido.
Camada de servidor
É a camada que neutraliza o backdoor antes mesmo de ele executar. O guia oficial de hardening do WordPress reforça boa parte destas práticas:
- Bloqueio de execução PHP em /uploads: regra no Nginx ou Apache que impede a execução de qualquer .php no diretório de mídia, anulando o shell mais comum.
- Web Application Firewall (WAF): filtra requisições maliciosas e exploração de CVEs conhecidas antes de chegarem à aplicação.
- Isolamento de processos PHP-FPM por site: impede que um site comprometido contamine os vizinhos no mesmo servidor.
- Monitoramento de integridade de arquivos: alerta sempre que um arquivo do core ou de um plugin é modificado fora de um deploy legítimo.
- Backups versionados: permitem restaurar um estado limpo anterior à infecção sem perder conteúdo recente.
- SALTS rotacionados: invalidam sessões antigas e dificultam a persistência via cookies.
Esse nível de hardening em servidor é exatamente o que oferecemos na nossa hospedagem WordPress gerenciada. Se quiser aprofundar, reunimos mais materiais na nossa categoria de segurança para WordPress.
Perguntas frequentes sobre backdoor no WordPress
Quanto tempo um backdoor pode ficar escondido em um site WordPress?
Indefinidamente. Um backdoor bem ofuscado, isolado em uma subpasta de uploads ou registrado como tarefa agendada, pode permanecer ativo por meses sem causar sintomas visíveis. Ele só é descoberto quando o atacante decide usar o acesso, geralmente para spam, redirecionamentos ou roubo de dados.
Reinstalar o WordPress remove o backdoor?
Nem sempre. Reinstalar o core substitui apenas os arquivos do núcleo. Se o backdoor está em wp-content/uploads, em um plugin, no banco de dados ou em uma tarefa agendada, ele sobrevive. A limpeza precisa cobrir core, plugins, temas, uploads e banco simultaneamente.
É possível recuperar um site WordPress infectado sem perder conteúdo?
Sim. A limpeza dirigida remove apenas os arquivos maliciosos e as alterações injetadas, preservando posts, mídia e configurações legítimas. Backups versionados ajudam a restaurar um estado limpo recente sem sacrificar o conteúdo publicado entre a infecção e a descoberta.
Backdoors podem ser inseridos via banco de dados?
Sim. Além de usuários administradores fantasmas, atacantes injetam código em opções e tarefas agendadas armazenadas no banco. Por isso uma limpeza completa sempre inclui revisão das tabelas, não apenas dos arquivos.
Hospedagem WordPress gerenciada protege contra backdoors?
Reduz drasticamente o risco. Uma hospedagem WordPress gerenciada com WAF, bloqueio de execução PHP em uploads, isolamento de processos e monitoramento de integridade neutraliza os vetores mais comuns antes que o backdoor execute. Não substitui boas práticas de aplicação, mas elimina a maior parte da superfície de ataque.
Plugins de segurança gratuitos são suficientes?
São um bom ponto de partida, mas têm limites. Versões gratuitas de scanners costumam receber assinaturas de ameaças com atraso e dependem do PHP da própria aplicação, que pode estar comprometida. Para sites corporativos, o ideal é combinar plugin de scan com hardening em servidor.
Como evitar reinfecção depois de limpar o site?
Feche o vetor original. Identifique o plugin ou tema explorado, atualize ou remova, rotacione SALTS, resete senhas, revise o banco e ative bloqueio de execução PHP em uploads mais um WAF. Sem fechar a porta de entrada e a porta dos fundos, a reinfecção volta.
Conclusão
O backdoor no WordPress é um problema de persistência, não de aparência. O atacante explora um plugin desatualizado, planta um shell PHP em uploads, cria um admin fantasma e registra uma tarefa agendada. Limpar só o que aparece deixa a chave reserva no lugar, e a reinfecção volta em dias.
A solução completa combina três frentes: identificar os sinais e esconderijos, remover de forma dirigida cobrindo arquivos e banco de dados, e prevenir com hardening em servidor. Atualização, menor privilégio, 2FA, bloqueio de PHP em uploads, WAF e monitoramento de integridade formam a base que impede o problema de voltar.
É exatamente esse conjunto que entregamos na nossa hospedagem WordPress gerenciada, com hardening, WAF e monitoramento incluídos. Se o seu time vive apagando incêndio de segurança em vez de publicar conteúdo, fale com a gente e tire essa preocupação da sua operação.