PHP2Shell (CVE-2026-109618 e CVE-2026-109619): o que fazer já no seu PHP

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

1. 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.
2. 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.
3. Reinicie o PHP-FPM, o Apache e os workers. Um patch instalado com processos antigos em execução não protege.
4. 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.
5. Coloque uma WAF à frente, se ainda não tiver. A Cloudflare publicou regras para os vetores conhecidos, mas considera-as uma medida temporária.
6. 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).
7. Invalide as sessões de utilizadores e administradores depois da renovação.
8. 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.
9. 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:

1. Servidores expostos à internet com mod_php.
2. Sistemas que tratam dados de pagamento, de saúde ou credenciais (painéis, APIs de autenticação, checkout).
3. Máquinas em PHP 8.1 ou anterior, que precisam de backport ou de migração.
4. 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.