PHP2Shell: o que os donos de sites WordPress devem fazer já

O PHP2Shell é um par de vulnerabilidades críticas no próprio PHP, divulgadas a 21 de outubro de 2026 e classificadas com 9,2 na escala CVSS. Num ambiente PHP sem a correção, um atacante sem conta pode executar código no servidor ou ler memória que contém palavras-passe, tokens de sessão e chaves de API. Os investigadores demonstraram-no em instalações atuais do WordPress. Atualizar o WordPress, o tema ou os plugins não resolve: é a versão do PHP por baixo do seu site que tem de ser atualizada.

Este guia explica o que é o PHP2Shell, como verificar se o seu site está afetado, o que perguntar ao fornecedor de alojamento e o que fazer se a atualização não puder acontecer hoje.

O que é o PHP2Shell

A investigação da Wiz Research, da OpenAI Codex Security e da Calif encontrou duas classes relacionadas de falhas de segurança de memória no motor do PHP:

• CVE-2026-109618, corrupção por falta de memória. A forma como o PHP lida com o esgotamento da memória pode corromper o seu estado. Um atacante pode aproveitar isso para executar código como o processo web do PHP (worker), sem iniciar sessão.
• CVE-2026-109619, estado global residual entre pedidos. Os dados de um pedido podem sobreviver até ao pedido seguinte. Isto leva a um use-after-free que pode expor memória do worker ou executar código.

Como a falha está no PHP, o seu próprio código não precisa de conter qualquer erro. Segundo os investigadores, até uma página «Hello World» numa versão afetada do PHP pode ficar exposta. O WordPress, o Drupal e o Joomla foram simplesmente as aplicações usadas para demonstrar a execução remota de código sem autenticação. A equipa do PHP publicou versões corrigidas no mesmo dia.

Para um site WordPress, há duas consequências que pesam mais:

1. Tomada do servidor. Executar código como worker do PHP significa, em regra, que o atacante pode alterar ficheiros, criar um administrador, instalar uma backdoor ou chegar à base de dados.
2. Roubo silencioso de dados. A fuga de memória funciona sem executar código malicioso, por isso pode deixar poucos vestígios. A memória de um worker do PHP muito solicitado pode conter palavras-passe e cookies de outros visitantes, a palavra-passe da sua base de dados e chaves de API.

O meu site está afetado?

Quase de certeza, a menos que o seu PHP tenha sido atualizado a 21 de outubro de 2026 ou depois. Os investigadores encontraram versões afetadas desde o PHP 5.4. Estas são as primeiras versões corrigidas de cada ramo suportado:

O PHP 8.1, o 8.0 e todas as versões 7.x já não são suportados pelo projeto PHP e não constam desta tabela. Se o seu site usa uma delas, não há nenhuma versão corrigida para instalar: tem de passar para um ramo suportado.

Para ver a versão exata no WordPress, abra Ferramentas → Saúde do site → Informação e expanda Servidor. A linha «Versão do PHP» mostra o número completo, por exemplo 8.3.36. As duas primeiras partes (8.3) não chegam: o que conta é o último número.

Como corrigir

A única correção completa é um ambiente PHP corrigido, seguido de um reinício.

1. Atualize o PHP em todos os ambientes. No seu próprio servidor, instale os pacotes atualizados da sua distribuição assim que forem publicados, ou a versão oficial de php.net. Em alojamento gerido ou partilhado, é o fornecedor que atualiza o PHP; pergunte-lhe diretamente se o seu plano já usa a versão corrigida.
2. Reinicie o PHP. Um pacote PHP novo não tem efeito enquanto os processos em execução não forem substituídos. Reinicie o PHP-FPM, o Apache com mod_php e quaisquer workers PHP de longa duração.
3. Confirme o resultado. Volte a abrir a Saúde do site. A versão do PHP tem agora de ser igual ou superior à versão corrigida do seu ramo.
4. Não se esqueça dos outros ambientes. Sites de testes (staging), uma segunda versão do PHP selecionada no painel de alojamento, o PHP usado pelas tarefas cron e pelo WP-CLI e as imagens de contentores também contam.

Se usa um painel de alojamento com seletor de versão do PHP, escolher «8.3» ou «8.4» só é seguro se o fornecedor já tiver instalado a compilação corrigida por trás dessa etiqueta. A Saúde do site diz-lhe a verdade.

Se não puder atualizar hoje

Os investigadores indicam medidas temporárias. Cada uma bloqueia alguns caminhos de ataque, nenhuma os bloqueia todos e algumas podem afetar o seu site, por isso teste primeiro:

• fatal_error_backtraces = 0, se a sua versão do PHP o suportar.
• Baixe post_max_size e max_input_nesting_level tanto quanto os seus formulários e carregamentos permitirem, e defina session.upload_progress.enabled = 0 se nada usar o progresso de carregamento.
• Recicle os workers do PHP-FPM com mais frequência, com um pm.max_requests mais baixo (isto custa desempenho).
• memory_limit = -1 elimina o caminho do limite de memória de que alguns ataques dependem, mas entrega o esgotamento da memória ao sistema operativo. Use-o apenas com um limite do sistema operativo, como memory.max do cgroup v2, e nunca o substitua por RLIMIT_AS ou RLIMIT_DATA, que, segundo o aviso de segurança do PHP, podem desencadear o mesmo erro.

Esconder os erros do PHP (display_errors, error_reporting ou @) não é uma destas medidas: o projeto PHP diz que não ajuda.

Os fornecedores de firewall e de CDN publicaram regras para o PHP2Shell. Podem reduzir a exposição, mas os investigadores são claros: uma regra de proteção não substitui a atualização do PHP.

Sinais a que deve estar atento

Nenhuma linha de registo prova, sozinha, um ataque. Os investigadores apontam sinais que vale a pena investigar: cookies PHPSESSID invulgarmente grandes ou malformados nas respostas, pedidos multipart estranhos seguidos de erros de limite de memória ou de picos de respostas HTTP 500, e workers PHP que falham ou reiniciam sem motivo. A ausência destes sinais não prova que o site está limpo, porque a fuga de memória pode não deixar nada nos registos do WordPress.

Se vir estes sinais, trate a situação como um possível incidente. O nosso guia sobre os sinais de um WordPress pirateado ajuda nas primeiras verificações. Como a memória exposta pode conter segredos, depois de aplicar a correção mude a palavra-passe da base de dados, as chaves e salts em wp-config.php e todas as chaves de API. Se houver a possibilidade de dados pessoais terem sido expostos, o prazo do RGPD começa a contar: consulte o nosso guia de notificação de violações em 72 horas.

Por onde começar

1. Abra Ferramentas → Saúde do site → Informação → Servidor e anote a versão exata do PHP de cada site que gere.
2. Compare-a com a tabela acima. Tudo o que estiver abaixo da versão corrigida, ou em PHP 8.1 ou anterior, exige ação hoje.
3. Atualize o PHP ou peça ao fornecedor de alojamento a versão corrigida e confirme depois que o PHP-FPM ou o Apache é reiniciado.
4. Volte a verificar a Saúde do site e guarde a captura de ecrã como prova da correção.
5. Analise os registos à procura dos sinais acima e renove os segredos se algo parecer errado.

Fontes: php2shell.com, anúncio da PHP Foundation, Wiz Research.