Duas falhas, um lançamento de emergência
O projeto PHP publicou quatro versões de emergência em 21 de outubro — 8.5.12, 8.4.27, 8.3.36 e 8.2.35 — que corrigem duas vulnerabilidades com pontuação base CVSS v4.0 de 9,2 cada e que permitem execução remota de código sem autenticação. Os mantenedores publicaram junto um aviso pedindo aos operadores que atualizem já.
A primeira, CVE-2026-109618, é um erro de gestão de memória. O PHP usa longjmp() para abandonar o contexto atual quando fica sem memória, e o aviso descreve casos em que a memória do pedido é alcançável antes de estar totalmente inicializada. Se uma alocação falha nesse momento, a saída antecipada deixa essa memória inválida e o encerramento do pedido pode lê-la ou ramificar sobre ela. O aviso diz que um atacante pode chegar ao caminho pela análise multipart — um cabeçalho content-length ausente, excesso de cabeçalhos de parte, ou muitos controlos de ficheiro vazios com nomes de campo aninhados — e que isso pode levar a execução remota de código na conta do processo web.
A segunda, CVE-2026-109619, é um erro de estado residual: o estado interno pertencente a um pedido pode sobreviver depois de a sua memória ser libertada, pelo que um pedido posterior atendido pelo mesmo processo pode seguir essas referências soltas.
O aviso do PHP diz que o risco é maior no mod_php, mas que todas as instalações que servem web estão afetadas, nomeando PHP-FPM, php-cgi, FrankenPHP e LiteSpeed. O aviso do GitHub é mais preciso sobre até onde o trabalho chegou: descreve mod_php e FrankenPHP como os mais diretamente suscetíveis, enquanto o FPM é considerado suscetível por análise do código-fonte, sem que um exploit completo tenha sido demonstrado.
Onde entra a IA
A OpenAI publicou o seu próprio relato no mesmo dia. Num texto sobre o que chama Patch the Planet, a empresa diz que a firma de segurança Calif identificou uma falha crítica usando o GPT‑5.6 Sol, e que a Wiz descobriu e reportou ambas as vulnerabilidades de forma independente. Os mantenedores do PHP lideraram as correções e o lançamento.
A lista de créditos do aviso do GitHub bate com esse relato: nomeia quatro reportantes, entre eles identificadores terminados em -wiz e -oai, e quatro programadores de PHP que construíram a remediação.
O enquadramento da OpenAI é que o setor teve sorte no calendário. “Tanto quanto sabemos, a IA de fronteira encontrou estas vulnerabilidades antes dos atacantes”, escreve a empresa, “abrindo uma Janela do Defensor para que mantenedores e fornecedores de segurança preparassem correções e proteções antes da divulgação”. Chama ao par “um dos problemas de segurança mais relevantes da memória recente”, dada a difusão do PHP, e diz esperar que achados assim “aumentem acentuadamente nos próximos meses”. A par do texto, comprometeu mil milhões de dólares em acesso subsidiado ao seu produto de segurança Daybreak para organizações com poucos recursos, e disse ter contactado a Super Intelligence Force da Casa Branca, o Office of the National Cyber Director e a CISA antes da divulgação.
A versão da Cloudflare é menos confortável
A Cloudflare, que participou na mesma resposta coordenada, deu um nome ao par — php2shell — e publicou a sua própria análise, dizendo que qualquer servidor web a correr PHP 5.4 ou posterior está afetado. Diz ter começado a escrever regras de firewall de aplicações web no início de outubro e tê-las ligado cerca de nove horas antes da divulgação pública, com planos gratuitos e pagos protegidos por omissão a partir das 03:02 UTC de 21 de outubro.
Diz também que está a ver tráfego de ataque contra os seus clientes, e que os atacantes mudaram as cargas para tentar contornar as regras, com os seus analistas a seguir os volumes de correspondências para acompanhar as mutações. Isso não contradiz a afirmação da OpenAI de que os defensores encontraram os erros primeiro, mas estreita bastante a janela: na manhã da divulgação, alguém já tentava.
O que os operadores têm de fazer
Atualizar é a única correção completa. O aviso do PHP lista medidas provisórias — definir memory_limit=-1 através de php_admin_value e não de ini_set(), baixar o post_max_size, desativar session.upload_progress e, no 8.5, pôr fatal_error_backtraces=0 — e é explícito em que nenhuma delas torna a instalação segura. Avisa ainda contra RLIMIT_AS e RLIMIT_DATA, que podem acionar o caminho vulnerável.
O PHP 8.1 e anteriores já não recebem atualizações a montante, pelo que quem está nesses ramos depende de um backport da distribuição. As distribuições Linux e os fornecedores com suporte de longa duração receberam correções antecipadamente. O próprio PHP 8.2 chega ao fim de vida a 31 de dezembro de 2026.
A Cloudflare cita a W3Techs para o número de que o PHP corre em quase 70% dos sites. O valor a vigiar nas próximas duas semanas não é a pontuação de gravidade, mas a taxa de correção no alojamento partilhado, onde quem aplica a correção raramente é quem detém o site.
