PHP2Shell: Falhas críticas no PHP afetam mais gravemente os servidores mod_php

O PHP antecipou o lançamento da sua atualização de segurança para quarta-feira, 21 de outubro, às 14h UTC, depois de detalhes de duas falhas terem vazado no Hacker News no dia anterior. As correções estão incluídas no PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Ambas as falhas estão no próprio interpretador, e não em um CMS. Os avisos de segurança do PHP para CVE-2026-109618 e CVE-2026-109619 atribuem a cada uma a pontuação 9,2 no CVSS 4.0 e confirmam a execução remota de código sem autenticação, com os privilégios do processo de trabalho do servidor web.

Tratamento de falta de memória deixa a memória parcialmente inicializada

A primeira falha está na forma como o PHP lida com erros de falta de memória. Quando ocorre falta de memória (OOM), o interpretador usa longjmp() para sair do contexto atual, mesmo quando a memória da requisição está apenas parcialmente inicializada naquele momento. O procedimento de encerramento então lê esse estado como válido. Um invasor pode forçar a falta de memória com uma requisição multipart que permaneça abaixo de post_max_size, por exemplo, por meio de um número ilimitado de cabeçalhos por parte, campos de arquivo vazios que não são contabilizados em max_file_uploads ou nomes de campos aninhados. A correção substitui longjmp() por um tratamento não fatal de falta de memória no próximo ponto seguro da VM e por uma chamada imediata a _exit() ao ultrapassar um segundo limite, mais alto.

A segunda falha envolve um estado global que persiste após o fim de uma requisição. Se um erro fatal interromper uma operação antes que ela redefina seu estado, um campo global continua apontando para memória já liberada no heap. Quando a requisição seguinte no mesmo processo de trabalho lê esse valor antes da inicialização normal, o resultado é um uso após liberação de memória. O PHP lista dois caminhos confirmados: a configuração fatal_error_backtraces no PHP 8.5 e o acompanhamento do progresso de upload da sessão, que está ativado por padrão e não exige que a aplicação chame session_start().

Por que o mod_php é o mais exposto

O Apache com mod_php chama o procedimento de encerramento da requisição mesmo quando a inicialização da requisição já falhou. Basta que a memória se esgote enquanto o PHP analisa o corpo da requisição, sem que seja necessário executar qualquer código da aplicação. O PHP validou a execução completa de código contra o mod_php com os limites padrão de memória e de entrada. O PHP-FPM encerra um processo filho cuja inicialização falha, o que bloqueia o caminho direto. Para a segunda falha, o PHP ainda confirmou uma exploração contra um pool FPM normal, embora ela dependa de uma operação adequada na aplicação. A análise do código-fonte sugere que o FrankenPHP se comporta como o mod_php, enquanto o LSAPI é um candidato sob determinadas condições. A alta complexidade de ataque no vetor CVSS reflete o fato de que a compilação do PHP e a disposição do heap afetam a confiabilidade da exploração.

Tentativas de exploração e o papel da IA

A watchTowr afirma estar observando tentativas ativas de exploração de ambas as falhas, e a Cloudflare disse ao The Hacker News que detectou ataques iniciais antes do lançamento da correção. Até o momento, nenhum comprometimento bem-sucedido foi confirmado. Ainda assim, serviços do governo neerlandês, incluindo DigiD e MijnOverheid, foram retirados do ar por precaução, e o NCSC do Reino Unido recomenda retirar do ar os sistemas sem correção caso não haja outra opção disponível.

A Wiz Research encontrou as falhas e as comunicou em 24 de agosto. Segundo a Wiz, Gemini 4 Argon e GPT-5.6 Sol ajudaram na descoberta, no desenvolvimento da exploração e na validação das correções, especialmente no ajuste da exploração para cada alvo. A Wiz também credita à OpenAI e à Calif a ajuda na descoberta e na coordenação. Isso está alinhado com o que a Anthropic escreveu recentemente sobre IA que se autocopia e tem como alvo aparelhos de TV de baixo custo, em que os modelos também facilitam a realização de ataques.

O que os administradores devem fazer agora

Atualizar é a única correção completa. As distribuições Linux e os fornecedores de versões LTS receberam as correções antecipadamente e costumam adaptá-las para versões antigas, mantendo os números de versão anteriores. Por isso, procure os identificadores CVE no registro de alterações, em vez de se basear no número da versão. As linhas 7.4, 8.0 e 8.1, que já não têm suporte, recebem apenas adaptações mínimas das correções no código-fonte. Se não for possível atualizar imediatamente, o PHP recomenda definir memory_limit=-1 no nível administrativo, pois é o limite previsível por requisição que permite o funcionamento da exploração de falta de memória confirmada. Adicione session.upload_progress.enabled=0 e, no PHP 8.5, fatal_error_backtraces=0 e, em seguida, reinicie todos os processos de trabalho. Se a sua aplicação não usa formulários multipart, bloqueie-os no frontend. Nenhuma dessas configurações é uma correção completa. Em uma hospedagem compartilhada ou em um NAS com servidor web, verifique qual versão do PHP é fornecida pelo seu provedor.