Em resumo: a forma mais rápida de encontrar uma backdoor no WordPress é comparar o núcleo e os plugins com as somas de verificação oficiais através do WP-CLI e, depois, rever de forma orientada os mu-plugins, os uploads, o wp-config.php, as contas de administrador e a base de dados. Importante após o PHP2Shell: uma atualização do WordPress não fecha a vulnerabilidade do PHP e não remove nenhuma backdoor existente.
Porque é que os operadores de WordPress devem agora olhar com mais atenção
Com o PHP2Shell tornaram-se conhecidas, em outubro de 2026, duas vulnerabilidades críticas no próprio PHP, CVE-2026-109618 e CVE-2026-109619. Permitem a execução de código malicioso sem autenticação, independentemente de quão bem cuidada esteja a sua instalação WordPress. Há patches desde 21/10/2026, mas, segundo notícias dos meios de comunicação, uma primeira tentativa de ataque foi observada já a 17/10.
Quem esteve vulnerável neste período deve procurar vestígios. O WordPress é aqui um alvo típico, porque muitas instalações têm uma estrutura semelhante e os atacantes conhecem os esconderijos. O que os operadores têm de fazer sobre o PHP2Shell em geral está na página WordPress e PHP2Shell.
Faça as verificações seguintes, se possível, numa cópia ou depois de uma cópia de segurança. Os comandos só leem e não alteram nada.
Como nota uma backdoor no dia a dia
Uma backdoor foi concebida para passar despercebida. Mesmo assim, há sinais que se notam sem conhecimentos técnicos. Entre eles estão redirecionamentos para sites alheios que só surgem a visitantes vindos da pesquisa do Google ou apenas em dispositivos móveis. Também são suspeitas as páginas novas com publicidade a medicamentos, jogo ou cópias de produtos de marca, que aparecem no índice de pesquisa mas não no backend do WordPress.
Outros indícios são avisos do Google ou do navegador, queixas de clientes sobre e-mails de spam vindos do seu domínio, um consumo de tempo de computação subitamente muito mais alto no fornecedor de alojamento ou administradores que ninguém da equipa conhece. Nenhum destes sinais prova por si só uma backdoor. Se vários surgirem em conjunto, não adie as verificações seguintes.
Em sentido inverso: se nada disto chamar a atenção, isso não significa que a instalação esteja limpa. Precisamente as backdoors criadas apenas para um acesso posterior não mostram muitas vezes qualquer efeito para o exterior.
Encontrar backdoor no WordPress: verificar núcleo e plugins
O WP-CLI consegue comparar os ficheiros do núcleo do WordPress e dos plugins do diretório oficial com as somas de verificação publicadas. Qualquer desvio é uma tarefa concreta de verificação.
cd /var/www/meine-seite
# Ficheiros do núcleo face às somas de verificação oficiais
wp core verify-checksums
# Plugins do diretório oficial
wp plugin verify-checksums --all
# Versões instaladas e estado
wp plugin list
wp theme list
Os plugins e temas comerciais não podem ser verificados assim. Para esses, só ajuda a comparação com um pacote original acabado de descarregar do fornecedor. Plugins desconhecidos, que ninguém da equipa instalou, são sempre suspeitos, mesmo que pareçam desativados.
Esconderijos típicos no sistema de ficheiros
Alguns locais surgem repetidamente em instalações WordPress comprometidas:
wp-content/mu-plugins/: é carregado automaticamente e não aparece na lista normal de plugins.wp-content/uploads/: ali pertencem imagens e documentos, não ficheiros PHP.wp-config.php: linhasincludeourequireadicionais no início ou no fim..htaccesse.user.inina pasta web e em subpastas: redirecionamentos inesperados ou ficheiros pré-carregados automaticamente.- Ficheiros na pasta principal cujos nomes fazem lembrar ficheiros do núcleo do WordPress, mas que não pertencem lá.
# Ficheiros PHP na pasta de uploads
find wp-content/uploads -type f -name "*.php*"
# Conteúdo dos plugins must-use
ls -la wp-content/mu-plugins/
# Todos os ficheiros .htaccess e .user.ini com data de alteração
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Ficheiros PHP alterados recentemente
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Os padrões gerais de pesquisa de código ofuscado estão descritos no guia Detetar e remover webshells.
Verificar utilizadores, base de dados e tarefas agendadas
Muitas backdoors nem sequer estão no sistema de ficheiros. Uma conta de administrador adicional basta muitas vezes aos atacantes para voltarem mais tarde.
# Todos os administradores com data de registo
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Tarefas agendadas no WordPress
wp cron event list
# Endereço do site (manipulações levam a redirecionamentos)
wp option get siteurl
wp option get home
# Publicações com scripts incorporados
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Verifique também opções com conteúdos invulgarmente grandes e widgets com código alheio. Os resultados não significam automaticamente um ataque, pois códigos de acompanhamento ou mapas incorporados também usam scripts. O decisivo é se alguém da equipa conhece o conteúdo.
Depois de um achado, mude todas as palavras-passe e as chaves de segurança no wp-config.php. Caso contrário, as sessões iniciadas pelos atacantes continuam válidas.
Fechar backdoors e evitar o regresso
Se encontrou uma backdoor, uma reinstalação costuma ser mais segura do que reparar ficheiros isolados. Esta sequência tem-se revelado eficaz:
- Guardar vestígios: registos, ficheiros suspeitos e uma exportação da base de dados, com data.
- Levar o PHP a uma versão corrigida e reiniciar todos os processos PHP.
- Instalar de novo o núcleo do WordPress, os plugins e os temas a partir de fontes originais.
- Aproveitar os uploads e a base de dados depois de verificados, apagar contas alheias e mudar todos os acessos.
- Impedir a execução de PHP na pasta de uploads ao nível do servidor.
Para o Nginx basta, para isso, um bloco na configuração do servidor:
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
No Apache obtém o mesmo com uma regra na configuração do servidor para a pasta de uploads. Um .htaccess na própria pasta de uploads é mais fraco, porque um atacante com permissões de escrita pode voltar a alterá-lo.
Depois da limpeza, preveja algumas semanas de observação mais apertada. Novos administradores, novos ficheiros PHP e alterações ao wp-config.php devem, nesse período, ser notados de imediato, por exemplo através de uma verificação regular com o WP-CLI ou de uma monitorização de ficheiros no servidor.
Como definir depois as permissões dos ficheiros de modo que o WordPress só possa escrever onde é necessário, mostra-o o guia Permissões de ficheiros no servidor web.
Como ajuda concretamente a PHP SOS?
- Guardamos o estado da instalação, antes de alterar o que quer que seja.
- Verificamos núcleo, plugins, temas, base de dados, contas e configuração do servidor quanto a backdoors.
- Reinstalamos o WordPress a partir de fontes limpas e aproveitamos apenas conteúdos verificados.
- Reforçamos a segurança do servidor e da instalação e documentamos o que foi encontrado e corrigido.
O procedimento de uma limpeza está descrito no serviço Mandar remover malware e webshells.
Perguntas frequentes
Uma atualização do WordPress fecha a vulnerabilidade PHP2Shell?
Não. O PHP2Shell está no interpretador PHP, não no WordPress. Uma atualização do WordPress, dos temas ou dos plugins não altera isso; o decisivo é o estado do PHP no servidor e o reinício de todos os processos PHP.
Um plugin de segurança encontra todas as backdoors?
Não de forma fiável. Um plugin corre dentro da instalação comprometida e pode ele próprio estar manipulado. Complemente-o com verificações a partir do exterior, por exemplo somas de verificação do WP-CLI e uma comparação com ficheiros originais limpos.
O que são mu-plugins e porque são suspeitos?
Os plugins must-use da pasta wp-content/mu-plugins são carregados automaticamente e não aparecem na lista normal de plugins. Os atacantes gostam de os usar porque os operadores raramente olham para esta pasta.
Uma backdoor também pode estar na base de dados?
Sim. O código malicioso ou os redirecionamentos são muitas vezes guardados em opções, publicações ou widgets. Além disso, os atacantes criam frequentemente contas de administrador próprias, que encontra na tabela de utilizadores.