O plano que a OpenAI propõe para falhas do PHP

Em 21 de outubro de 2026, a OpenAI publicou uma proposta de divulgação coordenada em cinco etapas durante a resposta a duas vulnerabilidades críticas do PHP. Divulgação coordenada é o processo de organizar a correção e a comunicação de uma falha entre mantenedores, organizações afetadas, fornecedores de segurança e governos, antes de publicar orientações para os operadores.

A proposta detalha quem participa, que informações cada grupo deve receber e em quais situações o cronograma pode ser revisto. A OpenAI pediu contribuições de mantenedores, pesquisadores, equipes de resposta, fornecedores e operadores; o texto apresenta o processo como uma proposta.

As cinco etapas propostas pela OpenAI

A sequência começa com a validação e a correção do problema no software original e termina com orientações públicas depois que existe um patch, ou seja, uma atualização que corrige a falha.

1. Validar e corrigir a falha: mantenedores, pesquisadores e parceiros técnicos confirmam o impacto, desenvolvem e testam a correção. A proposta também prevê testes adversariais com modelos de fronteira para procurar formas de contornar o patch e falhas relacionadas.
2. Dar tempo às organizações afetadas: mantenedores decidem quem precisa ser envolvido. Distribuidores podem adaptar correções para versões antigas; provedores de hospedagem podem testar medidas de redução de risco; e fornecedores de segurança podem preparar detecção ou bloqueio, por exemplo, por meio de um firewall de aplicação web.
3. Coordenar a resposta com governos: agências podem ajudar a organizar a resposta e encaminhar orientações a serviços essenciais e infraestruturas críticas. No caso do PHP, a OpenAI disse ter envolvido parceiros do governo dos Estados Unidos e parceiros internacionais.
4. Preparar atualizações para os produtos afetados: quando as correções, as orientações e os planos de divulgação estiverem mais definidos, distribuidores, provedores de serviços, equipes de resposta e operadores podem preparar atualizações e identificar lacunas de cobertura.
5. Publicar orientações e apoiar a instalação: depois que há um patch, as instruções públicas devem ajudar operadores a identificar sistemas afetados, localizar atualizações ou medidas provisórias, conferir se a correção está em execução e pedir ajuda.

O fluxo proposto é: corrigir a falha original, preparar quem depende do software, coordenar a resposta, organizar atualizações posteriores e publicar instruções após a existência de um patch.

Quando o cronograma pode ser revisto

A proposta da OpenAI prevê reavaliar os prazos se houver exploração ativa, vazamento de informações, publicação de um patch que revele a falha ou atrasos na correção que aumentem o risco aos usuários.

O compartilhamento também deve ser limitado à informação necessária para cada participante realizar seu trabalho de proteção. A proposta orienta ponderar o risco de revelar esses detalhes, mesmo que de forma limitada, em relação à proteção que essa divulgação pode viabilizar.

A OpenAI deixou para discussão o tempo adequado de preparação, os critérios para avisos em etapas e as salvaguardas para uma correção emergencial de sistemas que o operador possui ou está autorizado a administrar. Varreduras em escala da internet e correções emergenciais por governos ou outros operadores também aparecem como questões para receber comentários, não como procedimentos já definidos.

As falhas do PHP e as versões corrigidas

PHP é uma linguagem de programação executada em servidores para atender requisições de sites e aplicações. As duas vulnerabilidades podem permitir execução remota de código sem autenticação em instalações que processam requisições web. O PHP atribuiu a cada uma nota 9,2 na escala CVSS 4.0.

A CVE-2026-109618 envolve corrupção de dados durante uma situação de falta de memória: o processamento pode ser interrompido enquanto dados internos da requisição ainda estão parcialmente inicializados, e a rotina de limpeza pode tratá-los como válidos. A CVE-2026-109619 envolve estado global obsoleto: dados internos de uma requisição podem permanecer após a liberação da memória que os sustentava e ser usados por outra requisição no mesmo worker antes de serem reinicializados.

O PHP listou estas versões corrigidas:

As configurações de servidor citadas pelo PHP incluem PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O aviso avalia o risco como mais alto em mod_php. Para o contexto das correções, a NeoTeo também publicou uma matéria sobre as versões do PHP que corrigem as duas falhas.

O PHP 8.1 e versões anteriores não recebem atualizações do projeto PHP. Para as ramificações 7.4, 8.0 e 8.1, o projeto publicou backports mínimos do código-fonte; distribuições Linux e fornecedores de suporte de longo prazo também podem oferecer pacotes com correções retroportadas. Nesses casos, o operador precisa consultar o fornecedor do pacote para saber o estado da correção.

O que as medidas temporárias conseguem fazer

As medidas provisórias do PHP reduzem a exposição a caminhos específicos, mas não tornam uma instalação segura. O projeto considera a atualização para uma versão corrigida a solução completa.

Para a CVE-2026-109618, o PHP recomenda remover a possibilidade de uma falha de limite de memória controlável com memory_limit=-1, restringir o tamanho de requisições e usar limites de contêiner ou cgroups como barreira para a disponibilidade do sistema. Para a CVE-2026-109619, recomenda desativar session.upload_progress.enabled antes do processamento das requisições e reiniciar todos os workers. No PHP 8.5, fatal_error_backtraces=0 bloqueia apenas o caminho confirmado ligado a rastreamentos de erros fatais.

Essas medidas cobrem caminhos determinados, não substituem a instalação de uma versão corrigida. Se uma distribuição ou fornecedor fornece PHP com uma versão antiga, a correção pode estar em um backport; o estado do pacote deve ser consultado com esse fornecedor.