Lançamento de emergência do PHP: duas RCEs críticas corrigidas em 8.2.35 a 8.5.12
O PHP publicou um lançamento de segurança fora do calendário que corrige duas vulnerabilidades críticas de use-after-free no núcleo da linguagem, ambas exploráveis para execução remota de código sem autenticação e ambas com 9,2 na escala CVSS v4.0. As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicadas hoje e listadas no arquivo de lançamentos do projeto. Backports mínimos de código-fonte para os ramos 7.4, 8.0 e 8.1, sem manutenção há muito tempo, existem apenas no GitHub - não há binários oficiais para eles.
O lançamento foi precedido por uma janela de divulgação caótica. Em 20 de outubro o projeto anunciou uma publicação de emergência para hoje às 14:00 UTC sem nomear versões ou funções afetadas; conforme documentado pela OX Security, capturas de tela de uma ferramenta de exploração circularam antes de os patches estarem disponíveis, e o próprio projeto avisou que código proof-of-concept circulando nessa janela costuma ser malware disfarçado. Agora que patches e avisos são públicos, o panorama técnico é mais claro do que o ciclo de teasers sugeria.Um caminho de falta de memória para a execução de código
A CVE-2026-109618, registrada como GHSA-w8hw-w9fx-j79w, abusa de como o PHP lida com o esgotamento de memória. Quando uma alocação falha, o motor desenrola a requisição com um longjmp() - e se isso acontece enquanto a memória da requisição está apenas parcialmente inicializada, a fase de encerramento lê ou desvia depois sobre memória em estado inválido. O aviso descreve uma família de truques de pressão de alocação que tornam isso alcançável a partir de uma requisição HTTP comum: corpos multipart sem um content-length utilizável que escorregam para além do post_max_size, partes com milhares de cabeçalhos cuja representação em memória ofusca seu tamanho no fio, e controles de arquivo vazios que alocam arrays de metadados sem nunca contar contra o max_file_uploads. O SAPI mod_php do Apache está confirmado como explorável: pesquisadores validaram execução remota de código sem autenticação como a conta do worker web sobre HTTP puro em configurações prefork padrão - com alta complexidade de ataque e possivelmente várias tentativas. O PHP-FPM é considerado suscetível por caminhos de alocação específicos da aplicação, com FrankenPHP e LiteSpeed provavelmente no mesmo barco. O patch substitui o longjmp bruto por uma armadilha suave de falta de memória no próximo ponto seguro da VM, além de uma falha dura que mata o worker de imediato.Estado obsoleto em processos worker
A CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) é a irmã silenciosa: processos worker carregam estado global - tratadores de erro, dados de sessão, contabilidade de objetos e extensões - que pode acabar apontando para memória pertencente a uma única requisição. Se um erro fatal, um aborto por falta de memória ou um diagnóstico tardio escreve esse estado e nada o reinicia antes de a memória da requisição ser liberada, os globais do worker ficam soltos. O que primeiro os tocar antes de uma nova requisição inicializar lerá memória liberada. Dois caminhos de produção estão confirmados: os rastros de erro fatal introduzidos no PHP 8.5 sob mod_php e o mecanismo session upload progress sob mod_php e FPM. Produtor e consumidor precisam cair no mesmo processo worker, o que torna pools FPM com muitos workers mais difíceis - mas não impossíveis - de acertar.Um layout de heap estrategicamente elaborado pode produzir execução remota de código (RCE) completa. - Aviso de segurança do PHP, GHSA-6wmf-4rv5-p3rp
O que os administradores devem fazer agora
Atualizar é a única mitigação completa, e este não é um caso de aplicar o patch e esquecer: ambos os avisos enfatizam reiniciar todos os workers PHP depois da atualização, porque estado obsoleto pode sobreviver em processos de vida longa. Ramos suportados têm binários de lançamento; sites presos a ramos EOL precisam aplicar os backports de código-fonte por conta própria.- Atualizar para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 (ou aplicar os backports do GitHub para 7.4/8.0/8.1) e depois reiniciar todos os processos worker.
- Se atualizar hoje não for possível: definir session.upload_progress.enabled=0 e, no PHP 8.5, fatal_error_backtraces=0, e reiniciar os workers.
- Para a falha de OOM, impor memory_limit=-1 centralmente e verificar que nenhum override de pool ou .htaccess restaure um limite finito.
- Manter um post_max_size conservador, bloquear requisições multipart no frontend se a aplicação não as usa e limitar variáveis de entrada, cabeçalhos e uploads.
- Usar limites de memória de contêiner/cgroup em vez de RLIMIT_AS ou RLIMIT_DATA - o aviso alerta explicitamente que os mecanismos RLIMIT empurram falhas de alocação para o caminho vulnerável.
- Opcionalmente, limitar a reciclagem de workers com pm.max_requests para encurtar a janela de arraste de estado.