Em resumo: a vulnerabilidade PHP de que agora se fala não está no WordPress, mas no PHP do servidor que lhe serve de base. Por isso, uma atualização do WordPress não corrige o PHP2Shell. O que conta é o estado do patch do PHP, o reinício de todos os processos PHP e a verificação dos esconderijos habituais, como wp-content/uploads e mu-plugins.
Porque é que uma atualização do WordPress não resolve o PHP2Shell
O WordPress é uma aplicação escrita em PHP. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 situam-se um nível abaixo, no próprio interpretador PHP. Segundo a equipa do PHP, permitem a execução remota de código malicioso sem autenticação. Com o Apache e mod_php foi demonstrado um exploit antes de qualquer código do WordPress ser executado.
Um site com o núcleo atualizado, plugins atualizados e palavras-passe fortes pode, portanto, continuar vulnerável se o PHP por baixo for antigo. Inversamente, um PHP com patch não prova que nada tenha acontecido antes. Explicamos o contexto em O que é o PHP2Shell?.
| Nível | Quem atualiza | Corrige o PHP2Shell? |
|---|---|---|
| Núcleo do WordPress | Você ou a sua agência | Não |
| Plugins e temas | Você ou a sua agência | Não |
| PHP no servidor | Fornecedor de alojamento ou administrador do servidor | Sim, juntamente com o reinício de todos os processos PHP |
Vulnerabilidade PHP no WordPress: verificar a versão do PHP
No painel de controlo, em Ferramentas > Estado do site > Informações, na secção «Servidor», encontra a versão do PHP com que o seu site realmente corre. Isto é mais fiável do que php -v na linha de comandos, porque a linha de comandos usa muitas vezes uma instalação PHP diferente da do servidor web.
Ainda assim, o número apresentado não basta. As versões upstream corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Muitos fornecedores de alojamento, porém, incorporam as correções como backport; nesse caso continua a aparecer um número mais antigo, embora o patch esteja aplicado. Como apurar o estado real está em Verificar corretamente a versão e o estado do patch do PHP. Quais as versões do PHP que a sua versão do WordPress suporta, verifique-o nos requisitos de sistema em wordpress.org.
Onde o código malicioso gosta de se esconder no WordPress
Depois de um ataque bem-sucedido, os atacantes costumam deixar uma backdoor para poderem voltar mesmo depois do patch. O WordPress tem locais conhecidos para isso:
- wp-content/uploads/: destinada a imagens e PDF, não a ficheiros PHP.
- wp-content/mu-plugins/: os plugins «must-use» carregam automaticamente e não podem ser desativados no painel de controlo.
- wp-config.php: contém o acesso à base de dados e as chaves de segurança; uma linha inserida passa aqui quase despercebida.
- .htaccess na pasta principal e em subpastas: redirecionamentos apenas para motores de busca ou a execução de extensões de ficheiro invulgares.
- Temas, sobretudo
functions.php, bem como plugins desativados e esquecidos. - Base de dados: novos administradores em
wp_users, JavaScript estranho emwp_optionsou em artigos.
Primeiras verificações inofensivas com WP-CLI e ferramentas do sistema:
# Comparar os ficheiros do núcleo com as somas de verificação oficiais
wp core verify-checksums
# Verificar os plugins do diretório em wordpress.org
wp plugin verify-checksums --all
# Listar os ficheiros PHP na pasta de uploads
find wp-content/uploads -type f -name "*.php"
# Mostrar todos os administradores
wp user list --role=administrator
Um resultado é motivo para uma análise rigorosa, ainda não uma prova. Os plugins comerciais não podem ser verificados desta forma. Encontra mais pormenores no guia Encontrar backdoors no WordPress.
Não apague ficheiros suspeitos precipitadamente. Guarde primeiro os ficheiros, a base de dados e os registos do servidor a partir de 20/10/2026. Sem estes vestígios não será possível esclarecer mais tarde se houve fuga de dados.
Plugins, temas e acessos de administrador como risco adicional
O PHP2Shell não precisa de uma falha num plugin. No dia a dia, porém, os plugins e os temas continuam a ser a porta de entrada mais frequente nos sites WordPress. Cada plugin traz código próprio, funções de upload próprias e ciclos de atualização próprios. Os plugins que não usa devem ser eliminados e não apenas desativados, pois os ficheiros desativados continuam no servidor.
Para wp-login.php e wp-admin aplica-se: poucos administradores, contas pessoais em vez de acessos partilhados e autenticação de dois fatores. Se não precisar do XML-RPC, pode bloqueá-lo. Perante uma suspeita, devem renovar-se todas as palavras-passe e as chaves de segurança em wp-config.php. O editor de ficheiros do painel de controlo também se desativa aí:
define( 'DISALLOW_FILE_EDIT', true );
O que deve fazer agora como operador de WordPress
- Pedir ao fornecedor de alojamento que confirme por escrito o estado do patch do PHP e o reinício de todos os processos PHP.
- Pedir que sejam conservados os registos do servidor a partir de 20/10/2026.
- Efetuar as verificações acima ou mandá-las efetuar.
- Atualizar o WordPress, os plugins e os temas. Isto é correto, mas não substitui o passo 1.
- Em caso de anomalias, não continuar simplesmente a operar o site, mas mandá-lo limpar.
Uma atualização da plataforma pode corrigir falhas conhecidas no WordPress e nos plugins. Não consegue reparar o PHP nem remover ficheiros introduzidos que não pertencem ao núcleo.
Como ajuda concretamente a PHP SOS?
- Esclarecemos consigo ou com o seu fornecedor de alojamento o estado real do PHP do seu site WordPress, incluindo backports e reinício.
- Guardamos registos, ficheiros e base de dados antes de alterar o que quer que seja.
- Verificamos no núcleo, nos plugins, nos uploads, nos mu-plugins, no
.htaccesse nas contas de utilizador se existem backdoors. - Em caso de descobertas, a nossa remoção de malware assegura a limpeza até o incidente estar concluído e documentado; sem descobertas, reforçamos a instalação no âmbito da ajuda imediata PHP2Shell.
Perguntas frequentes
Tenho de atualizar o WordPress por causa do PHP2Shell?
Um WordPress atualizado é sempre aconselhável, mas não corrige o PHP2Shell. A falha está no interpretador PHP do servidor. Para isso é preciso uma atualização do PHP ou um backport confirmado pelo seu fornecedor de alojamento, e o reinício de todos os processos PHP.
Um plugin de segurança protege contra o PHP2Shell?
Só de forma muito limitada. Um plugin é ele próprio código PHP que corre dentro do WordPress. Com o mod_php foi demonstrado um exploit antes de o código da aplicação sequer arrancar; um plugin pode, por isso, nem chegar a aperceber-se do ataque.
Porque é que o WordPress ainda mostra uma versão antiga do PHP, apesar de o fornecedor ter aplicado o patch?
Muitos fornecedores de alojamento e distribuições Linux incorporam as correções como backport na versão existente. O número de versão mantém-se então igual. Peça ao fornecedor que lhe confirme por escrito o estado do patch.
Pode existir um ficheiro PHP em wp-content/uploads?
Normalmente não. A pasta de uploads destina-se a ficheiros multimédia. Um ficheiro PHP aí é um sinal de alerta claro e deve ser guardado e analisado por especialistas antes de ser apagado.