PHP2Shell: PHP corrige duas falhas de execução remota encontradas com ajuda de IA, e vazamento antecipa exploits

Fala aí, beleza? O PHP soltou ontem, 21/10/2026, versões de segurança que corrigem duas falhas no próprio motor da linguagem, e o assunto é sério: elas podem permitir execução remota de código sem autenticação

O lançamento estava previsto pra 22/10, mas um vazamento antecipou tudo em um dia. Segundo o post da PHP Foundation, o time de segurança monitorou as provas de conceito que surgiram depois do vazamento e não identificou nenhum exploit funcional até o momento da divulgação pública

As falhas são a CVE-2026-109618 e a CVE-2026-109619, apelidadas de PHP2Shell, com severidade oficial CVSS 9.2 (CVSS v4.0) cada uma

Quais versões do PHP corrigem o PHP2Shell e como atualizar

As versões corrigidas são estas:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

O anúncio oficial do php.net é direto: não existe mitigação completa, atualizar é a única escolha segura e todos os usuários devem atualizar imediatamente

Ou seja, não adianta esperar o plugin do WordPress ou o módulo do Drupal soltar correção, beleza? O problema não está neles

Onde baixar as versões corrigidas

Depende de como o PHP chegou no seu servidor:

1. Compila a partir do código-fonte: o código está na página de downloads do php.net
2. Usa Windows: código e binários estão na mesma página de downloads do php.net
3. Usa pacotes de distribuição Linux ou de fornecedor LTS: essas distribuições e fornecedores receberam os patches com antecedência, então o caminho é conferir com o próprio fornecedor se o pacote atualizado já está disponível

Tome cuidado com o terceiro caso!

O número de versão de um pacote de distribuição pode não bater com a numeração do php.net: a Sansec dá o exemplo de um pacote corrigido que mantém o número antigo (por exemplo, 8.1.34) e ganha só uma nova release do pacote. Pra confirmar que o patch entrou, procure a CVE no changelog do próprio pacote, não confie só no número que aparece

E quem está em PHP 7.4, 8.0 ou 8.1?

Esses ramos não recebem mais atualizações oficiais do projeto PHP. Mas, dada a gravidade das falhas, o time de segurança publicou backports mínimos de código-fonte para PHP 7.4, 8.0 e 8.1

Além disso, algumas distribuições e fornecedores LTS oferecem correções retroportadas para esses ramos: vale conferir com o fornecedor do seu pacote antes de assumir que não há correção disponível

Checagem final

Depois de atualizar, confira a versão do PHP que está rodando de fato em produção (não só a que está instalada na máquina) e compare com a versão corrigida do seu ramo

Tem que ser igual ou superior a ela

Quem é afetado: WordPress, Drupal, Joomla e qualquer PHP que atende requisições web

A falha está no motor do PHP, não em uma aplicação específica

Por isso a lista de afetados é tão grande: segundo o próprio advisory oficial do php.net, toda instalação PHP que atende requisições web é afetada, incluindo:

• PHP-FPM
• Apache com mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

O mesmo advisory aponta o risco como maior em configurações com Apache e mod_php

Além disso, a Wiz Research afirma ter conseguido RCE sem autenticação contra WordPress, Drupal e Joomla

E tem mais um ponto que preocupa…

Segundo a Wiz, existe um caminho separado de vazamento de memória capaz de expor senhas, tokens, chaves de API e certificados

Essas duas últimas são alegações da própria Wiz, vale deixar claro: mas são motivo suficiente pra não deixar a atualização pra semana que vem

Atualização de 22/10: exploração em massa é menos provável, mas o risco continua

A Sansec publicou uma atualização em 22/10 dizendo que a exploração em massa é menos provável do que se temia: o ataque precisa de conhecimento específico do servidor e de condições específicas, e as provas de conceito públicas não funcionam contra uma instalação PHP padrão

Mesmo assim, a própria Sansec reforça: atualize o PHP de qualquer forma

O que são as falhas CVE-2026-109618 e CVE-2026-109619

As duas são problemas de memória dentro do motor do PHP, e o post da PHP Foundation descreve cada uma assim:

• CVE-2026-109618: se a requisição atinge o memory_limit no momento errado, o PHP pode deixar dados internos parcialmente inicializados e depois tratá-los como válidos, corrompendo memória
• CVE-2026-109619: um erro fatal pode deixar estado interno apontando para memória liberada, que uma requisição posterior atendida pelo mesmo worker pode acabar usando; a Foundation confirma que é um use-after-free com crash de worker

Use-after-free? 🤔

É quando o programa continua usando um pedaço de memória que já foi liberado, e alguém mal-intencionado pode tentar colocar ali o conteúdo que quiser

A severidade oficial é CVSS 9.2 (CVSS v4.0) para cada CVE, confirmada também pela Sansec e pelo The Next Web: o 10.0 que circulou durante o vazamento estava errado

Cloudflare WAF protege contra o PHP2Shell? Só como paliativo

Ajuda, mas não resolve

A Cloudflare implantou proteções de WAF contra o php2shell a partir de 21/10 às 03:02 UTC, cerca de 9 horas antes da divulgação pública, aplicadas automaticamente em todos os planos com WAF, incluindo o Free

Mas se liga: WAF é uma camada na frente do servidor, não uma correção do motor

A própria Cloudflare afirma que os clientes devem atualizar o PHP mesmo com a proteção do WAF ativa, e relata ter observado tráfego de ataque contra clientes já nesse período, com atacantes alterando o payload ao longo do tempo. O anúncio oficial do PHP reforça que não existe mitigação completa sem a atualização

Como o vazamento antecipou o lançamento e acelerou os exploits

A divulgação coordenada deu errado na véspera, e a linha do tempo da PHP Foundation mostra como:

1. 20/10, por volta das 15:00 UTC: os dois IDs de CVE começaram a circular em fóruns e redes sociais, com horário de lançamento errado e CVSS 10.0 (o correto é 9.2). Segundo a Foundation, nenhum detalhe técnico vazou nesse momento
2. 20/10, 19:30 UTC: o projeto PHP antecipou e publicou o pré-anúncio, movendo o lançamento de 22/10 às 14:00 UTC para 21/10 às 14:00 UTC
3. 20/10, por volta das 20:00 UTC: a Calif, uma das empresas que reportaram as falhas, publicou por engano um vídeo com a prova de conceito funcionando contra vários alvos, revelando alguns detalhes adicionais, embora limitados
4. 20/10, por volta das 23:00 UTC: o projeto também enviou orientações de mitigação a alguns provedores de infraestrutura crítica. Segundo a PHP Foundation, essas orientações também podem ter vazado
5. Depois disso: o vídeo da Calif foi apagado, mas cópias circularam nas redes e contribuíram para acelerar o desenvolvimento de PoCs (provas de conceito de exploração)
6. 21/10, 07:41 UTC: mais de seis horas antes da divulgação coordenada, a Chainguard quebrou o embargo unilateralmente e publicou imagens já com a correção

Vale um ajuste importante aqui: a Sansec afirma que a watchTowr já havia confirmado RCE em 20/10, ainda antes da divulgação oficial de 21/10. Então não dá pra resumir o episódio como "só ruído": o vazamento dos IDs circulou sem detalhe técnico, segundo a Foundation, mas outra empresa de segurança diz ter confirmado a exploração no mesmo dia, por caminho próprio

O vídeo publicado por engano acelerou o desenvolvimento de provas de conceito, mas a própria PHP Foundation pondera que o possível vazamento das orientações de mitigação enviadas a provedores de infraestrutura crítica também pode ter contribuído: não dá pra atribuir a aceleração só ao vídeo

Segundo a Foundation, nenhum exploit funcional foi identificado até o momento da divulgação pública. Mas vale notar que, nesse mesmo período, a Cloudflare já relatava ter observado tráfego de ataque contra clientes: ou seja, a situação no terreno não era de calma total enquanto o time de segurança ainda monitorava os desenvolvimentos

IA na descoberta: Calif, Wiz e OpenAI reportaram a mesma causa raiz

As falhas foram reportadas por três grupos diferentes, e a PHP Foundation documenta datas de parte desses contatos:

1. 11/08/2026: Ryan A, da Calif, reporta RCE com a mesma causa raiz, durante uma auditoria do PHP iniciada em 30/07 pelo programa Patch the Planet
2. 24/08/2026: a Wiz Research reporta vetores de exploração
3. 18/09/2026: a OpenAI reporta, de forma independente, vetores adicionais para a mesma causa raiz, com crédito ao OpenAI Codex Security

A Foundation não especifica a data exata do primeiro contato da OpenAI sobre a causa raiz: 18/09 é a data citada para os vetores adicionais, não necessariamente o primeiro report da empresa. Por isso não dá pra afirmar com certeza a ordem exata entre os três reports externos

Vale ainda uma ressalva anterior a todos eles: a própria Foundation diz que um desenvolvedor do core do PHP já tinha percebido os primeiros sinais do problema de falta de memória em 2024, enquanto corrigia um problema reportado pela Quarkslab: antes de qualquer um desses reports externos de RCE

O que a Wiz Research afirma

A Wiz diz ter usado as ferramentas Wiz Atlas, Gemini 4 Argon e GPT-5.6 Sol ao longo da pesquisa que resultou no report de 24/08, incluindo as demonstrações de RCE contra WordPress, Drupal e Joomla e o vazamento de memória citados mais acima. Segundo o The Next Web, a Wiz afirma ter chegado às falhas de forma independente, semanas depois da Calif

O que é a Calif e o Patch the Planet

Segundo reportagem do The Next Web, a Calif encontrou a primeira falha em agosto com ajuda do GPT-5.6 Sol, durante a auditoria financiada pela OpenAI pelo programa Patch the Planet

O Patch the Planet é uma iniciativa da OpenAI lançada em 22/06/2026 junto com a Trail of Bits, para achar e corrigir vulnerabilidades em software open source: engenheiros de segurança revisam os achados das ferramentas de IA antes de chegarem aos mantenedores do projeto. Foi dentro desse programa que a Calif conduziu a auditoria do PHP

O ponto interessante aqui é o padrão: múltiplos grupos, usando ferramentas de IA, caçando o mesmo tipo de bug de memória num projeto gigante e maduro como o PHP: com a ressalva de que, no caso específico do report da OpenAI, as fontes não detalham quais ferramentas foram usadas, além do crédito ao OpenAI Codex Security

Próximo passo: atualize o PHP antes de qualquer outra coisa

A ordem que faz sentido é esta:

1. Liste todos os servidores e containers que rodam PHP, incluindo aquele ambiente de staging esquecido que ninguém lembra que existe haha
2. Atualize cada um para a versão corrigida do ramo (8.2 a 8.5) ou aplique o backport correspondente (7.4, 8.0, 8.1), pelo php.net ou pelo fornecedor de pacotes
3. Confira a versão que está rodando de fato depois do deploy, olhando a CVE no changelog se for pacote de distribuição
4. Só então revise WAF e as outras camadas de proteção

Para acompanhar novidades, as referências são o anúncio do php.net e o post da PHP Foundation linkados ao longo do texto

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.