PHP2Shell (CVE-2026-109618/109619): o que fazer já

Resumo (atualizado a 23/10/2026): PHP2Shell é o nome dado a duas falhas críticas no próprio PHP, a CVE-2026-109618 e a CVE-2026-109619, ambas com CVSS v4 9,2. Permitem execução remota de código sem autenticação e, no caso da 109619, fuga de memória do processo, o que pode expor palavras-passe, tokens e chaves de API de outros pedidos. Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Depois, renove os segredos: o patch fecha a porta, mas não desfaz o que já possa ter sido exposto. Houve tentativas de exploração antes da divulgação.

Na terça-feira, 21 de outubro de 2026, o projeto PHP publicou correções de emergência para duas vulnerabilidades descobertas pela Wiz Research, pela Calif e pela OpenAI, em coordenação com a equipa de segurança do PHP. O nome diz tudo: o caminho vai do interpretador PHP diretamente para uma shell no servidor.

Este artigo destina-se a quem precisa de decidir depressa: CTOs, equipas de infraestrutura, responsáveis por sites WordPress e gestores de risco. Não há aqui detalhes de exploração, apenas o que fazer, por que ordem e como demonstrar que foi feito.

O que aconteceu

São duas falhas distintas no núcleo do PHP, não num plugin nem numa framework:

CVE-2026-109618 (corrupção por falta de memória). O tratamento de out-of-memory pode interromper o PHP quando os dados internos do pedido estão apenas parcialmente inicializados. A limpeza do pedido trata esses dados inválidos como válidos, o que permite executar código com os privilégios do utilizador do servidor web.
CVE-2026-109619 (estado global obsoleto). Um estado interno do pedido pode sobreviver depois de a respetiva memória ter sido libertada (use-after-free no heap). Um pedido seguinte, tratado pelo mesmo worker, pode usar esse estado antes de ser reinicializado. Resultado: fuga de memória do processo e execução remota de código sem autenticação.

A Wiz demonstrou execução remota de código sem autenticação em instalações de WordPress, Drupal e Joomla, bem como a leitura de memória sensível do processo. Segundo a Help Net Security, a rede de honeypots da Amazon registou uma tentativa de exploração a 17 de outubro, quatro dias antes da divulgação. O CTO da Cloudflare confirmou ataques iniciais, segundo o BleepingComputer. A 23/10/2026 as CVE não constavam do catálogo KEV da CISA, mas isso não quer dizer que o risco seja teórico: já foram observadas tentativas.

Quem está mais exposto

Todas as instalações de PHP que respondem a pedidos web são afetadas: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O maior risco está no Apache com mod_php, em que o interpretador corre dentro do processo do servidor web.

Versões corrigidas:

Ramo	Versão corrigida	Situação
8.5	8.5.12	Com suporte
8.4	8.4.27	Com suporte
8.3	8.3.36	Com suporte
8.2	8.2.35	Com suporte
8.1, 8.0, 7.4 e anteriores	Sem versão oficial	Sem suporte; o projeto publicou backports mínimos de código-fonte para 7.4, 8.0 e 8.1, e algumas distribuições aplicam correções próprias

Um pormenor importante: em Debian, Ubuntu, RHEL e derivadas, o pacote pode estar corrigido sem que o número de versão mude, porque a distribuição faz backport do patch. Olhar apenas para o X-Powered-By ou para o php -v pode enganar nos dois sentidos. Consulte o changelog do pacote.

Estão também numa posição mais delicada:

sites em PHP 8.1 ou anterior, que dependem de backports;
alojamento partilhado, em que não controla quando o PHP é atualizado;
servidores que guardam segredos em variáveis de ambiente ou na memória do processo (praticamente todos).

Faça já: lista de verificação por ordem

Confirme a versão real no servidor, não pela web. Execute php -v e php-fpm -v (ou o binário equivalente) em cada máquina. Nunca publique uma página phpinfo() para verificar.
Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Se utiliza pacotes da distribuição, verifique no changelog se a CVE-2026-109618 e a CVE-2026-109619 constam como corrigidas.
Reinicie o PHP-FPM, o Apache e os workers. Um patch instalado com processos antigos em execução não protege.
Se não puder atualizar hoje, aplique as mitigações parciais recomendadas pela equipa do PHP (reduzem a exposição, mas, nas palavras do próprio projeto, nenhuma bloqueia totalmente os ataques):
- Para a 109618: memory_limit=-1 através de php_admin_value na configuração do FPM ou do Apache; post_max_size baixo (8M sem carregamentos, 32M com carregamentos); limites de memória por contentor ou cgroup.
- Para a 109619: session.upload_progress.enabled=0; no PHP 8.5, fatal_error_backtraces=0; remova definições inválidas que geram mensagens de diagnóstico.
Coloque uma WAF à frente, se ainda não tiver. A Cloudflare publicou regras para os vetores conhecidos, mas considera-as uma medida temporária.
Renove os segredos. É o passo mais esquecido e provavelmente o mais importante, porque a 109619 permite ler memória de outros pedidos. Dê prioridade a:
- palavras-passe da base de dados;
- chaves de API de terceiros (pagamentos, e-mail, SMS, CRM);
- chaves de sessão e salts (no WordPress, as constantes AUTH_KEY, SECURE_AUTH_KEY e semelhantes no wp-config.php);
- tokens OAuth e segredos de assinatura JWT;
- credenciais de cloud (chaves de acesso AWS, GCP, Azure).
Invalide as sessões de utilizadores e administradores depois da renovação.
Reveja os registos desde ~17/10: picos de erros 500, mensagens de out of memory, carregamentos multipart invulgares e reinícios anómalos de workers.
Procure sinais de comprometimento: ficheiros PHP novos em pastas de carregamento, web shells, administradores criados recentemente, tarefas agendadas desconhecidas.

Notas para WordPress

O WordPress é o caso mais frequente e foi um dos alvos demonstrados. Três cuidados específicos:

Alojamento gerido: pergunte ao fornecedor, por escrito, que versão e que build do PHP está em uso e quando foi aplicado o patch. Guarde a resposta como evidência.
Salts: gerar novos valores no wp-config.php termina todas as sessões, que é precisamente o que pretende depois da renovação.
Os plugins não são a causa, mas agravam o dano. Um atacante com execução de código lê o wp-config.php, por isso considere a palavra-passe da base de dados exposta se o servidor esteve vulnerável.

Como definir prioridades numa frota

Quem gere dezenas de servidores não consegue tratar de tudo ao mesmo tempo. Uma ordem sensata:

Servidores expostos à internet com mod_php.
Sistemas que tratam dados de pagamento, de saúde ou credenciais (painéis, APIs de autenticação, checkout).
Máquinas em PHP 8.1 ou anterior, que precisam de backport ou de migração.
Ambientes internos e de pré-produção, que muitas vezes partilham segredos com a produção.

Registe, para cada máquina: versão antes e depois, data do patch, mitigação aplicada e segredos renovados. Esse registo é o que auditores, clientes empresariais e seguradoras vão pedir, sobretudo em contextos abrangidos pelo RGPD, pela NIS2 ou pelo DORA.

Como a Pentest Machine pode ajudar

Atualizámos a nossa própria infraestrutura para o PHP 8.4.27 e aplicámos a mitigação de session.upload_progress logo após a divulgação. A partir dessa experiência criámos uma resposta PHP2Shell com âmbito fechado:

inventário de versão e SAPI (mod_php, FPM, CGI) de cada servidor no âmbito;
revisão de registos à procura de sinais de exploração;
plano de renovação de segredos por prioridade;
relatório executivo com evidências para auditoria e clientes;
reteste depois das correções.

Entregamos em 72 horas após a concessão de acesso. Recebe uma proposta com preço fechado em 24 horas: peça um orçamento.

Quer apenas uma primeira visão? O nosso Raio-X de Segurança Externa é gratuito e passivo e passou a assinalar indícios de PHP exposto. Não envia qualquer carga de ataque e não consegue confirmar se o patch foi aplicado: serve para saber por onde começar.

Perguntas frequentes

O que é o PHP2Shell?

É o nome dado a duas vulnerabilidades críticas no núcleo do PHP, a CVE-2026-109618 e a CVE-2026-109619, divulgadas a 21/10/2026. Permitem execução remota de código sem autenticação e fuga de memória do processo.

Que versões do PHP corrigem a falha?

PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.1 e anteriores não recebem versão oficial; foram publicados backports mínimos de código-fonte para 7.4, 8.0 e 8.1, e algumas distribuições disponibilizam pacotes corrigidos.

Basta atualizar o PHP?

Não. O patch impede novos ataques, mas a CVE-2026-109619 permite ler memória de outros pedidos. Se o servidor esteve exposto, renove palavras-passe, chaves de API, salts e tokens e invalide as sessões.

O meu site está atrás da Cloudflare. Estou protegido?

Em parte. A Cloudflare publicou regras de WAF para os vetores conhecidos, mas trata-as como temporárias. Atualizar o PHP continua a ser obrigatório.

Como sei se o meu WordPress foi afetado?

Confirme a versão do PHP junto do fornecedor ou no servidor, reveja os registos desde 17/10 à procura de erros 500 e de out of memory, procure ficheiros PHP novos em wp-content/uploads e administradores criados recentemente. Na dúvida, renove os segredos.

Um scanner externo consegue dizer se estou vulnerável?

Não com certeza. A versão está muitas vezes oculta e as distribuições corrigem sem alterar o número. Um scanner passivo, como o Raio-X, aponta indícios de exposição; a confirmação exige acesso ao servidor.