CVE-2026-109618: falha crítica em PHP

CVE-2026-109618 é uma falha de corrupção de memória no núcleo do PHP, não em framework ou plugin. Quando uma alocação falha (OOM), o PHP sai do contexto atual com longjmp(). Alguns contextos deixam a memória da requisição não inicializada, e o shutdown depois lê ou desvia com base nessa memória. O PHP classifica a falha como RCE sem autenticação (CVSS v4.0 9.2, AC:H/AT:P). O vetor prático é uma requisição multipart que esgota a memória. Há relatos de ataques iniciais, ainda sem detalhes técnicos públicos, e a correção só existe nas versões 8.2.35, 8.3.36, 8.4.27 e 8.5.12.

O PHP trata OOM com longjmp() para abandonar a requisição. O problema está nos contextos que, antes do salto, expõem memória da requisição ainda não totalmente inicializada. Se qualquer alocação falhar nesse intervalo, o salto deixa a memória em estado inválido. Segundo o advisory, a alocação que falhou não precisa ter relação com a memória inválida. O shutdown então lê essa memória ou desvia com base nela. O atacante não controla diretamente o ponteiro. Ele controla o momento da exaustão de memória, e é isso que dá confiabilidade à exploração.

O advisory (GHSA-w8hw-w9fx-j79w) lista estratégias de OOM, e todas passam pelo parsing multipart (RFC 1867): (1) multipart sem Content-Length utilizável pode passar na checagem inicial de post_max_size e continuar entregando corpo decodificado; (2) uma parte multipart pode ter número ilimitado de headers, e a representação interna usa bem mais memória que o tamanho no fio, então uma requisição dentro de post_max_size esgota o memory_limit; (3) controles de arquivo vazios não contam em max_file_uploads, mas ainda geram os arrays de metadados, e nomes de campo aninhados multiplicam o trabalho.

O CVE é irmão do CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, estado global obsoleto). O advisory do 109619 manda seguir também a remediação do 109618. Ele é quem descreve os casos concretos de consumo da memória corrompida: fatal_error_backtraces no PHP 8.5 e o ciclo de vida do session upload progress. Fontes secundárias divergem sobre qual dos dois CVEs abriga cada bug, e o Precursor Security atribui ao 109618 um use-after-free no unserializer do upload progress. Trate os dois advisories como um conjunto.

O CWE específico deste CVE não foi confirmado no advisory que li. Uma fonte secundária (DEV Community) lista CWE-416, 755, 824, 1325 e 1419 para o par de CVEs. Tratei isso como referência e não como classificação oficial.

A correção remove o longjmp() para OOM, evitando a saída antecipada de contextos que não a tratam. Segundo o Precursor Security, o OOM passa a ser tratado como falha suave no próximo ponto seguro da VM. Segundo o ma.ttias, o PHP ganhou um segundo limite de memória, mais alto, que encerra o processo imediatamente, sem executar shutdown functions.

O vetor é de rede, sem autenticação e sem interação do usuário. O CVSS marca AC:H e AT:P: o atacante precisa levar o processo a um OOM no ponto certo e depois fazer a memória corrompida ser consumida. O advisory discute a complexidade assim: uma falha explorável sem variável específica do alvo tem complexidade menor que uma que exige customização não trivial. Para este CVE, os três métodos de OOM descritos usam multipart. Não encontrei pré-condição de autenticação, e o Patchstack relata que a Wiz Research demonstrou RCE contra imagens recentes de WordPress, Drupal e Joomla e que até um Hello World seria explorável. Não consegui confirmar isso em fonte primária.

O SAPI importa. O PHP considera o risco maior no mod_php, onde há exploit funcional disparado por requisição sem autenticação antes de qualquer código da aplicação. O advisory do 109619 diz que o caso do fatal error backtrace tem RCE confirmado contra mod_php e que o ciclo de sessão foi validado em mod_php e FPM. Segundo o Precursor Security, o Apache executa o shutdown mesmo quando o startup falha, e o FPM encerra o filho nesse caso, o que bloqueia esse caminho. Existiria porém uma rota pós-startup via unserializer. Esse detalhe é de fonte secundária. Todos os SAPIs de servir web (FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) são considerados em risco. O resultado é execução de código com os privilégios do worker web. A Wiz também demonstrou leitura da memória do worker, que pode conter senhas, tokens e chaves de API, sem chegar a RCE.

Sobre exploração ativa: o dado de que não há artefato conhecido está desatualizado. Vazou uma captura de uma ferramenta chamada PHP2Shell, atribuída à Calif.IO, que alega funcionar desde o PHP 5.4.0. A watchTowr diz ter reproduzido o CVE-2026-109618. O CTO da Cloudflare disse ver ataques iniciais, e a Patchstack disse ter confirmado múltiplos incidentes, mas nenhuma das duas publicou evidência técnica. Segundo a SOCRadar, o CVE não estava no KEV da CISA em 21/10/2026. Não verifiquei o KEV depois dessa data. Sem EPSS disponível. Assuma que exploração é viável e que a janela entre o diff do patch e ataques em massa é curta.

Atualize para 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, conforme o ramo. Depois de aplicar, o PHP passa a ter um hard memory limit adicional. Se você usou memory_limit = -1 como paliativo, volte para um limite real (o ma.ttias avisa isso). Para 7.4, 8.0 e 8.1, que não têm release oficial, o time de segurança do PHP publicou backports mínimos em código-fonte para quem compila por conta própria ou não tem fornecedor com backport. Quem usa pacote de distribuição deve checar o status do CVE no tracker do fornecedor, e não assumir pela versão exibida, porque backports mantêm o número antigo.

Se não puder atualizar, os paliativos listados pelo PHP reduzem caminhos específicos e, nas palavras do próprio PHP, não tornam a instalação segura. (1) Reduza post_max_size: 8M para apps sem upload, 32M para apps com upload, e mantenha upload_max_filesize abaixo disso. (2) Defina session.upload_progress.enabled=0 em php.ini, pool FPM ou config do servidor e reinicie todos os workers. (3) No PHP 8.5, defina fatal_error_backtraces=0 e reinicie os workers. (4) Corrija fatal errors e timeouts de execução alcançáveis pelo atacante. (5) Imponha limites de tamanho de requisição, número de campos e número de partes multipart no servidor web ou proxy. (6) Bloquear multipart/form-data antes do PHP cobre todas as estratégias de OOM descritas no advisory, mas quebra todo upload pelo navegador. Esse bloqueio aparece em fontes secundárias, e o PHP o recomenda para apps que não usam multipart.

O que não funciona: ini_set() e .user.ini não aplicam a tempo, pois os valores precisam estar em php.ini, no pool FPM ou na config do servidor, aplicados antes do parsing da requisição. Desligar upload progress e o backtrace fecha apenas os caminhos confirmados, não variantes. Um limite de memória alto ou ilimitado não resolve e pode virar DoS.

Não há indicador confiável e específico. O advisory do CVE-2026-109619 afirma que caminhos de estado obsoleto podem ocorrer sem entrada de log previsível, e o mesmo vale para a corrupção por OOM, que tende a gerar ruído genérico. Sinais citados por fontes secundárias: requisições multipart incomuns (muitos headers por parte, muitos campos de arquivo vazios ou aninhados, ausência de Content-Length utilizável) seguidas de erros de limite de memória ou HTTP 500 repetidos; cookies PHPSESSID anormalmente grandes ou malformados nas respostas (Patchstack); segfaults no log do PHP-FPM desde 20/10/2026 por volta das 15:00 UTC, quando os detalhes vazaram; arquivos .php e .user.ini novos ou alterados; processos filhos do usuário web.

A ausência desses sinais não prova que o ambiente está limpo. Preserve logs do servidor web e do PHP antes de aplicar o patch ou rotacionar. Havendo suspeita, reconstrua o host e rotacione os segredos acessíveis ao worker.