PHP anuncia correção emergencial para duas vulnerabilidades críticas

O PHP lançou atualizações emergenciais para corrigir duas vulnerabilidades críticas que permitem a invasores executar códigos remotamente em servidores web sem necessidade de autenticação. As falhas, conhecidas como PHP2Shell, foram identificadas como CVE-2026-109618 e CVE-2026-109619, receberam pontuação 9,2 no CVSS v4.0 e já são alvo de tentativas de exploração.

As correções foram disponibilizadas em 21 de outubro de 2026, nas versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Segundo a equipe de segurança do projeto, a atualização é a única medida capaz de corrigir completamente as vulnerabilidades.

O problema está no próprio mecanismo de execução do PHP, e não em aplicações específicas. Isso significa que até sites com código seguro, incluindo páginas simples, podem ser vulneráveis caso utilizem uma versão afetada. O aviso oficial aponta que praticamente todas as versões desde o PHP 5.4 são atingidas.

As vulnerabilidades afetam diferentes formas de execução da linguagem, incluindo PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. O cenário mais crítico envolve servidores Apache que utilizam mod_php, nos quais uma das técnicas demonstradas permite executar código malicioso por meio de uma única requisição não autenticada, antes mesmo que a aplicação seja iniciada.

No PHP-FPM, as condições de exploração variam. Uma das vulnerabilidades foi considerada potencialmente explorável, embora não tenha sido demonstrada uma cadeia completa de ataque nesse ambiente. A outra teve execução de código comprovada tanto no mod_php quanto no PHP-FPM, mas neste último caso depende de uma operação realizada pela aplicação.

Além da execução remota de código, os pesquisadores demonstraram que as falhas podem permitir a leitura de informações diretamente da memória dos processos PHP. Entre os dados potencialmente expostos estão senhas, tokens de autenticação, chaves de API e certificados utilizados por outras requisições, mesmo sem que o invasor consiga executar comandos no servidor.

As descobertas foram realizadas por pesquisadores da Wiz Research, Calif e da equipe Codex Security, da OpenAI, que trabalharam em conjunto com o time de segurança do PHP e especialistas do Google Gemini para desenvolver as correções.

Cloudflare e watchTowr identificam tentativas de exploração

A Cloudflare informou ter detectado tráfego associado a tentativas de exploração das vulnerabilidades antes da publicação dos patches. A empresa implementou regras emergenciais de proteção, ativadas por padrão às 03h02 UTC de 21 de outubro, e observou invasores modificando suas cargas maliciosas para tentar contornar os bloqueios.

A watchTowr também confirmou, em uma atualização publicada às 14h19 UTC, que estava observando tentativas ativas de exploração das duas vulnerabilidades.

Apesar dessa atividade, não havia confirmação pública de comprometimento bem-sucedido de servidores específicos até a última atualização das informações. As falhas também ainda não constavam no catálogo Known Exploited Vulnerabilities (KEV) da CISA no momento das verificações citadas.

O cenário levou algumas organizações a suspender serviços preventivamente. A BambooHR retirou sua plataforma do ar nos Estados Unidos, Canadá e Irlanda, alertando que operações relacionadas à folha de pagamento poderiam ser interrompidas.

Na Holanda, serviços públicos como MijnOverheid e DigiD, além do site da Câmara Baixa do Parlamento, do centro nacional de cibersegurança e de sistemas educacionais, também ficaram temporariamente indisponíveis. Segundo a emissora NOS, as interrupções foram adotadas como precaução, sem confirmação de ataques bem-sucedidos.

Quais versões do PHP precisam ser atualizadas?

A equipe do PHP confirmou as seguintes versões corrigidas:

Versão do PHP	Primeira versão corrigida
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

As versões PHP 8.1 e anteriores não recebem mais atualizações regulares do projeto. Entretanto, a equipe disponibilizou correções de código-fonte adaptadas para as séries 7.4, 8.0 e 8.1, permitindo que fornecedores e administradores responsáveis por compilações próprias implementem as mudanças.

Distribuições Linux também podem incorporar as correções aos seus pacotes sem modificar o número principal da versão instalada. Por isso, administradores devem consultar os avisos de segurança e históricos de alterações dos fornecedores para verificar se os respectivos CVEs foram corrigidos.

A atualização precisa ser aplicada ao ambiente de execução do PHP, seguida da reinicialização dos serviços e processos persistentes afetados. Atualizar plataformas como WordPress ou Laravel, isoladamente, não elimina as vulnerabilidades.

Medidas temporárias não substituem atualização

O comunicado oficial apresenta configurações que podem reduzir determinados caminhos de exploração, mas ressalta que nenhuma delas oferece proteção completa.

Para a CVE-2026-109618, as recomendações incluem utilizar memory_limit=-1, manter limites reduzidos para post_max_size e restringir o tamanho das requisições nos servidores web ou proxies. A equipe também alerta que limites de recursos como RLIMIT_AS e RLIMIT_DATA não devem ser utilizados como substitutos, pois podem acionar o mesmo comportamento vulnerável.

Para a CVE-2026-109619, é recomendado desativar o Session Upload Progress por meio da configuração session.upload_progress.enabled=0 e reiniciar os processos PHP. Na versão 8.5, também é indicada a configuração fatal_error_backtraces=0.

Essas mudanças podem bloquear caminhos conhecidos de ataque, mas não impedem todas as variantes. O recurso Session Upload Progress, ativado por padrão, participa de uma das técnicas confirmadas de exploração, porém sua desativação não protege contra a CVE-2026-109618.

Após instalar as correções, administradores também devem revisar as configurações de memória. A atualização introduz um limite rígido que pode encerrar processos quando atingido, impedindo inclusive a execução de rotinas de finalização.

Entre os possíveis indicadores de atividade suspeita estão requisições multipart incomuns, erros de limite de memória, respostas HTTP 500 repetidas, cookies PHPSESSID anormalmente grandes e reinicializações inesperadas de processos PHP.

Vazamento antecipou divulgação das falhas

A divulgação coordenada das vulnerabilidades estava inicialmente prevista para 22 de outubro, mas informações publicadas antecipadamente em 20 de outubro levaram o projeto PHP a antecipar as atualizações.

Segundo a PHP Foundation, a situação foi agravada quando a Calif publicou acidentalmente um vídeo demonstrando um exploit funcional, por volta das 20h UTC de 20 de outubro. Na manhã seguinte, às 07h41 UTC, a Chainguard disponibilizou imagens de software contendo as correções, permitindo que terceiros analisassem as mudanças antes da publicação oficial.

A PHP Foundation também revelou que os primeiros sinais do problema relacionado à CVE-2026-109618 haviam sido identificados durante uma auditoria externa realizada em 2024. Na ocasião, a possibilidade de exploração foi considerada teoricamente, mas não havia sido demonstrado um método concreto de execução remota de código.

O desenvolvimento de uma correção enfrentou dificuldades porque diferentes alternativas poderiam comprometer a compatibilidade do PHP, introduzir riscos de negação de serviço ou exigir alterações em extensões de terceiros. A discussão permaneceu sem resolução durante meses, situação que a fundação classificou como uma falha estrutural em seus processos de decisão e recursos disponíveis.

As investigações conduzidas em 2026 demonstraram a viabilidade prática dos ataques e aceleraram a implementação das correções. Segundo os pesquisadores, ferramentas de inteligência artificial ajudaram a transformar vulnerabilidades antigas em técnicas funcionais de exploração, reduzindo significativamente o tempo necessário para a pesquisa.

A PHP Foundation informou que, após o episódio, realizou mudanças em seus processos internos de segurança e ampliou recursos e ferramentas destinados à identificação e correção de vulnerabilidades semelhantes.