PHP corrigiu hoje as duas falhas críticas. O PoC já era público

Hoje, 21 de Outubro, o PHP publicou as correcções para duas vulnerabilidades que classifica de críticas: CVE-2026-109618 e CVE-2026-109619. As quatro versões corrigidas — 8.5.12, 8.4.27, 8.3.36 e 8.2.35 — fecham um caminho de execução remota de código, isto é, mandar executar código no servidor sem qualquer autenticação.

A pontuação é CVSS v4.0 9,2 em ambas, e as duas têm o mesmo endereço técnico: CWE-416, uso de memória depois de libertada. O projecto PHP não deixa margem para interpretação: «Não há mitigações completas; actualizar é a única opção segura».

O risco não é abstracto. O aviso do projecto é explícito sobre o pior cenário: em Apache com mod_php, «um exploit demonstrado mostra que um pedido não autenticado pode desencadear o ataque antes de correr qualquer código da aplicação».

Estão em causa todas as instalações que servem pedidos web — PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed — e o que fica ao alcance do atacante é código a correr com os privilégios do processo web.

O que se sabia ao meio-dia

A política do projecto PHP, ontem, foi avisar com antecedência. Em 20 de Outubro, o PHP anunciou uma release de segurança para quarta-feira, 21 de Outubro, às 14:00 UTC, para duas falhas «ambas classificadas com CVSS v4.0 9,2».

Reservou-se o direito de publicar mais cedo se a falha ou a exploração se tornassem públicas. Segundo o CERT-EU, a release acabou por sair às 13:30 UTC — trinta minutos antes do previsto.

Foi essa antecedência que deixou a porta encravar aberta. Numa altura em que o PHP ainda não tinha publicado nada, o Centro Nacional de Cibersegurança dos Países Baixos (NCSC-NL) já escrevia, no aviso que publicou hoje às 13:59, que «há código de prova de conceito (PoC) público» para as duas falhas — sem, ressalve, ter detectado exploração activa.

Mais tarde, ao actualizar o seu próprio advisory, o CERT-EU foi mais longe: os «PoCs iniciais começaram a circular» e isso «aumenta a probabilidade de que os atacantes já estejam a explorar». É uma apreciação de risco de uma agência, não um relato de ataque.

O que a correcção de hoje não apanha

É esta a parte que o número de versões corrigidas esconde. O PHP 8.1 e anteriores já não recebem actualizações do projecto: para 7.4, 8.0 e 8.1 o PHP publicou backports mínimos de código-fonte, que não são actualizações completas.

E o NCSC-NL vai mais longe — «todas as versões desde a versão 5 são, em qualquer caso, vulneráveis». O PHP 8.2, por seu lado, chega ao fim de vida a 31 de Dezembro de 2026 e deixa de receber correcções de segurança depois dessa data.

Há ainda um segundo círculo de exposição, menos visível: o software de terceiros. Muitos produtos comerciais e de código aberto usam PHP como tecnologia de suporte e podem estar afectados mesmo sem exporem uma instalação de PHP. O CERT-EU recomenda às organizações que consultem o repositório GitHub do NCSC-NL para identificar esse software embebido e medir a sua própria exposição.

O que a release de hoje resolve e o que não resolve, com a cronologia do dia. Esquema do Portugal Binário, construido a partir do aviso do PHP, do CERT-EU e do NCSC-NL.

As duas falhas têm o mesmo endereço técnico mas chegam lá por caminhos diferentes. Na CVE-2026-109618, o PHP aborta o pedido que ultrapassa o limite de memória configurado, e esse abortar pode apanhar o pedido a meio, por exemplo durante o envio de um ficheiro por formulário.

A limpeza posterior do pedido trata então como válidos dados que nunca foram inicializados e liberta memória que ainda contém valores de alocações anteriores controladas pelo atacante. Na CVE-2026-109619, o estado interno de um pedido sobrevive à libertação da memória que o sustentava, e um pedido seguinte, tratado pelo mesmo worker, pode usá-lo antes de a inicialização normal o repor.

Os dois caminhos descritos pelo CERT-EU e pelo php.net. Esquema do Portugal Binário: não é uma captura de ecrã e não reproduz código de exploração.

Os Países Baixos desligaram sites

É o efeito prático da antecedência. Às 15:13 de hoje, o governo neerlandês comunicava que «um número de websites foi colocado offline por precaução», por causa «de 2 furos no software usado em muitos websites», e que isso «incluía também websites de órgãos do governo».

O comunicado dá três exemplos: Overheid.nl, MijnOverheid.nl e DigiD — este último o sistema de identificação que os cidadãos usam para entrar em serviços públicos. O próprio NCSC-NL ficou temporariamente offline, a terminar a mesma tarde.

A lista completa veio da imprensa: ao longo da tarde, o NU.nl, o NRC e o AD passaram a referenciar o Tweede Kamer, o parlamento neerlandês, vários hospitais e empresas de transporte público entre os sites indispostos. O que o comunicado do governo acrescenta, e é a parte honesta, é que o Rijksoverheid.nl em si não usa PHP: o problema afecta os sites que dependem dele, não o portal principal.

Se não pode actualizar já

O php.net dá as medidas parciais, e é claro quanto valem: «só uma actualização corrige por completo estas vulnerabilidades» e as medidas seguintes «reduzem a exposição a caminhos de ataque específicos mas não tornam a instalação segura».

Para a falha de corrupção de memória (CVE-2026-109618): memory_limit=-1 aplicado de forma que a aplicação não o possa repor, post_max_size baixo (8M sem uploads, 32M com) e limites de tamanho de pedido, de número de campos e de profundidade de cabeçalhos no servidor ou no proxy.

Para a falha de estado global obsoleto (CVE-2026-109619): session.upload_progress.enabled=0 e reiniciar todos os workers; no PHP 8.5, também fatal_error_backtraces=0. E não use RLIMIT_AS nem RLIMIT_DATA, porque podem despoletar a falha de alocação que conduz ao caminho vulnerável.

Do CERT-EU vem ainda uma medida de isolamento: quando não for possível corrigir imediatamente, separar da rede pública as aplicações expostas até a correcção ser aplicada e verificada.

E uma nota de proportion, que o php.net também faz: a demonstração de que o ataque corre «antes de qualquer código da aplicação» é um caso demonstrado, não a prova de que cada instalação esteja a ser atacada. Prova de conceito não é exploração — mas, a partir de hoje, a distância entre as duas coisas passou a ser uma questão de tempo.

A decisão prática de hoje é simples de enunciar e difícil de executar: instalar uma destas quatro versões, hoje, e confirmar que o processo web passou a correr a versão nova. O que fica para amanhã é a lista que a correcção de hoje não apanhou — o PHP que ninguém actualiza, as aplicações que embebem PHP sem o expor, e o tempo que cada instalação demora a ser corrigida depois de o aviso circular.