O PHP lançou atualizações de emergência que corrigem duas falhas críticas na própria linguagem, permitindo que um invasor sem conta execute código em um servidor web. As correções estão nas versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, e a equipe do PHP afirma que apenas a atualização protege totalmente um servidor.
As falhas, chamadas em conjunto de PHP2Shell, estão no ambiente de execução do PHP, e não em nenhuma aplicação. Por isso, um site fica exposto mesmo quando o próprio código é seguro. O risco é maior em servidores que usam o mod_php do Apache, nos quais uma exploração funcional dispara o ataque antes que qualquer código da aplicação seja executado.
Ambas as falhas têm pontuação 9,2 na escala CVSS (Sistema de Pontuação de Vulnerabilidades Comuns) v4.0 e recebem os códigos de registro CVE (sigla de Vulnerabilidades e Exposições Comuns) CVE-2026-109618 e CVE-2026-109619. A PHP publicou as correções por volta do horário previsto para o lançamento, 14h UTC (Tempo Universal Coordenado) de 21 de outubro, um dia depois de detalhes vazarem antes da divulgação planejada para 22 de outubro.
Pesquisadores da Wiz, da Calif e da OpenAI encontraram e reportaram as falhas, que afetam quase todas as versões do PHP desde a 5.4.
Quem é afetado
Toda instalação do PHP que atende requisições web está em risco, incluindo o PHP-FPM (gerenciador de processos FastCGI do PHP), o mod_php do Apache, o php-cgi, o FrankenPHP e o LiteSpeed, de acordo com o comunicado de segurança do PHP.
Como as falhas estão no motor, e não no código de cada site, até uma página simples de “Olá, mundo” em uma versão vulnerável do PHP pode ser atacada.
O comunicado aponta o mod_php como o caso de maior risco, com uma exploração demonstrada na qual uma única requisição não autenticada dispara o ataque antes que qualquer código da aplicação seja executado. O PHP-FPM se comporta de forma diferente, porque encerra o processo trabalhador quando uma requisição falha logo no início da configuração.
Em uma das duas falhas, a análise do próprio PHP indica que o PHP-FPM é suscetível, mas afirma que ainda não foi demonstrada nenhuma exploração completa no FPM. A segunda falha foi comprovada como capaz de chegar à execução de código tanto no mod_php quanto no PHP-FPM, embora, no caso do FPM, o caminho dependa de uma operação dentro da aplicação em execução.
Um invasor também pode ler a memória do processo trabalhador do PHP, que pode conter senhas, tokens de autenticação, chaves de API (interface de programação de aplicações) e certificados pertencentes a outras requisições, sem antes conseguir executar código.
Os pesquisadores demonstraram essa leitura da memória ativa de um trabalhador contra aplicações que não controlavam, o que torna o problema independente da aplicação executada sobre o PHP.
O que instalar
Atualize o ambiente de execução do PHP que atende as requisições web e, em seguida, reinicie o Apache, o PHP-FPM e quaisquer processos trabalhadores de longa duração do PHP. Atualizar uma aplicação como WordPress ou Laravel não atualiza o ambiente de execução do PHP por baixo dela. Essa atualização vem do pacote do servidor, da hospedagem ou da imagem do contêiner.
O PHP 8.1 e as versões anteriores não recebem mais atualizações do projeto PHP, e o PHP 8.2 chega ao fim de vida em 31 de dezembro de 2026. Para os ramos antigos, a equipe de segurança do PHP publicou backports de código-fonte para o PHP 7.4, o 8.0 e o 8.1, para ajudar quem compila a partir do código-fonte ou aguarda um fornecedor.
As distribuições Linux e os fornecedores de suporte de longo prazo receberam as correções antecipadamente. Por isso, um pacote de distribuição pode trazer a correção com um número de versão que parece antigo. Verifique o changelog do pacote em busca do CVE, como recomenda a Debian, e não a string de versão.
Se não for possível atualizar agora
Somente a atualização é uma correção completa. As medidas abaixo reduzem a exposição a caminhos de ataque específicos e não tornam um servidor seguro, segundo o comunicado.
Para o CVE-2026-109618, defina memory_limit=-1 para que as aplicações não possam substituir o valor, mantenha post_max_size baixo e imponha limites de tamanho de requisição no servidor web ou no proxy. Não use RLIMIT_AS nem RLIMIT_DATA como substitutos, porque o PHP alerta que eles podem acionar o mesmo caminho vulnerável.
Para o CVE-2026-109619, defina session.upload_progress.enabled=0 e reinicie todos os trabalhadores. No PHP 8.5, defina também fatal_error_backtraces=0. Desativar o progresso de upload de sessão bloqueia os caminhos confirmados, mas não outras variantes, e nenhuma mudança de configuração corrige totalmente esta falha além da atualização.
Essa configuração é a que circulou como solução paliativa antes da correção, e a versão confirma que ela nunca foi uma correção completa. O progresso de upload de sessão vem ativado por padrão e pode alcançar o tratamento de sessões antes que o PHP termine de configurar uma requisição. Por isso, ele faz parte de um caminho de ataque confirmado para o CVE-2026-109619, e desativá-lo não faz nada contra o CVE-2026-109618.
“A única coisa que posso dizer é que a única mitigação é aplicar o patch ou atualizar o PHP. Infelizmente, sei demais”, escreveu o desenvolvedor principal do PHP Gina Peter Banyard antes do lançamento, em resposta a alguém que sugeriu que a configuração poderia bastar.
Após a atualização, revise suas configurações de memória. A correção adiciona um novo limite rígido de memória, e, ao atingi-lo, o processo é encerrado e os manipuladores de desligamento deixam de ser executados. Verifique memory_limit e post_max_size em relação ao que sua aplicação precisa.
Se você já aplicou a correção, mas suspeita de uma invasão anterior, os pesquisadores sugerem observar requisições multipart incomuns seguidas de erros de limite de memória ou respostas repetidas do HTTP (Protocolo de Transferência de Hipertexto) 500, cookies de resposta PHPSESSID (identificador de sessão do PHP) com tamanho incomumente grande e reinicializações inexplicadas dos trabalhadores do PHP.
Já há ataques em andamento?
Antes do lançamento da correção, a Cloudflare afirmou que já via tentativas iniciais de exploração das falhas. “Estamos observando ataques iniciais surgindo e atualizando as mitigações conforme novos vetores aparecem”, disse Dane Knecht, diretor de tecnologia (CTO) da Cloudflare, em declaração. Ele classificou as regras de firewall implantadas pela empresa como uma solução provisória e pediu que os administradores aplicassem a correção.
Nenhuma fonte confirmou uma invasão bem-sucedida. A watchTowr, que reproduziu o CVE-2026-109618, informou não haver exploração em circulação até as 11h26 UTC de 21 de outubro, e nenhuma das falhas constava no catálogo de Vulnerabilidades Exploradas Conhecidas da CISA (Agência de Segurança Cibernética e de Infraestrutura dos EUA) naquele momento.
Algumas organizações tiraram serviços do ar por precaução, e não em resposta a qualquer invasão. A BambooHR suspendeu seu serviço nos Estados Unidos, no Canadá e na Irlanda, alertou que a folha de pagamento seria interrompida e disse que ainda não tinha previsão de restabelecimento.
Na Holanda, o MijnOverheid, o DigiD, o site da Câmara dos Deputados, o centro nacional de segurança cibernética e vários sistemas de educação saíram do ar, informou a emissora NOS. O centro disse não ter visto a falha ser explorada, mas pediu que todos aplicassem a correção.
Como o caso veio à tona
Um vazamento antecipou a divulgação. Em 20 de outubro, como informou o The Hacker News, uma postagem no Hacker News afirmou que duas falhas de execução remota de código no PHP, com os dois identificadores CVE, seriam divulgadas em 22 de outubro, com base em nada além de uma dica considerada confiável.
Naquela noite, o PHP publicou um aviso antecipado e passou a divulgação para 21 de outubro. A alegação do vazamento de uma pontuação CVSS de 10,0 não partiu do PHP, que classifica as duas falhas com 9,2.
As falhas foram encontradas pela Wiz Research, pela Calif e pela equipe de segurança Codex da OpenAI, que trabalhou com a equipe de segurança do PHP e com a equipe Gemini do Google na correção. O código afetado estava no PHP havia mais de uma década.
Os pesquisadores afirmam que modelos de IA ajudaram a transformar essas falhas antigas em explorações funcionais, permitindo que um pesquisador fizesse em cerca de uma semana o que, segundo eles, levaria meses para uma equipe.
A Calif, que rastreou a origem do bug até pesquisas sobre o PHP de 2004, afirma que conhecer o histórico do alvo ainda fez diferença. Segundo a empresa, os modelos atuais não conseguem, de forma confiável, partir sozinhos de primitivas obscuras com vinte anos de idade.
Atualização: watchTowr relata tentativas de exploração, mas ainda não há invasão confirmada
A watchTowr, que no início do dia não havia identificado exploração, afirmou em um novo comunicado, às 14h19 UTC de 21 de outubro, que observa “tentativas ativas de exploração” dos CVE-2026-109618 e CVE-2026-109619. A Cloudflare disse ter registrado tráfego de ataque contra seus clientes e viu os atacantes alterarem suas cargas para contornar as regras de firewall, que foram ativadas por padrão às 03h02 UTC, antes da correção. Nenhuma fonte informou, até esta atualização, uma invasão confirmada a algum servidor específico.
O PHP Foundation afirmou que a divulgação coordenada fracassou antes do lançamento. Por volta das 20h UTC de 20 de outubro, a empresa de pesquisa Calif publicou por engano um vídeo de sua prova de conceito funcional. Às 07h41 UTC de 21 de outubro, cerca de seis horas antes do lançamento da correção, o fornecedor Chainguard publicou imagens de contêiner com o patch, permitindo que qualquer pessoa estudasse a correção enquanto outros usuários aguardavam para atualizar.
Atualização: PHP Foundation diz que uma auditoria de 2024 encontrou os primeiros sinais da falha
No mesmo comunicado, o PHP Foundation disse que um desenvolvedor principal identificou pela primeira vez sinais da falha de falta de memória por trás do CVE-2026-109618 durante a auditoria externa do PHP em 2024. Na época, porém, um ataque funcional apenas foi teorizado, e nenhum caminho concreto até a execução de código foi encontrado.
As propostas de correção concorrentes correram o risco de quebrar a compatibilidade, abrir caminhos de negação de serviço (DoS) ou forçar mudanças em extensões de terceiros. Como a pequena equipe teve dificuldade para chegar a um consenso, o trabalho na correção ficou parado por meses. A fundação chamou o atraso de “uma falha estrutural” em seu processo decisório e em seus recursos.
Os relatórios de 2026 da Calif, da OpenAI e da Wiz, que usaram ferramentas de IA, estabeleceram a exploração funcional que deixou clara a dimensão total da falha e colocaram a correção no topo da fila. A fundação afirmou que, desde então, mudou a forma como toma decisões de segurança e acrescentou equipe e ferramentas para identificar problemas semelhantes com mais rapidez.
(A notícia foi atualizada após a publicação, em 21 de outubro de 2026, para incluir relatos posteriores de tentativas de exploração e o relato do PHP Foundation sobre o histórico da falha.)
