O PHP publicou dois avisos críticos sobre falhas no gerenciamento de memória. Uma delas permite acessar memória já liberada de uma requisição anterior. A outra deixa estruturas inválidas após esgotamento de memória. Ambas têm execução remota de código demonstrada, mas as condições variam conforme a integração do PHP com o servidor. Confira a versão que atende às requisições do seu site e os ajustes específicos de cada ficha.
AplicativoPHP
Data do compilado
Vulnerabilidades2
As pontuações são do CVSS 4.0 informado nos avisos. As versões corrigidas indicam a disponibilidade da correção no projeto, sem confirmar a atualização do seu servidor. Compare cada faixa somente com a linha correspondente.
Gravidade críticaCVSS: 9,2/10Correção disponível
Estado global preservado entre requisições permite execução de código
O processo que atende às requisições pode conservar referências a estruturas de erro ou sessão depois que a memória da requisição foi liberada. Isso acontece quando um erro fatal interrompe a limpeza ou quando um diagnóstico recria informações de erro durante o encerramento. Na requisição seguinte, certas etapas de configuração e acompanhamento de uploads acessam essas referências antes da inicialização normal do PHP. Esse acesso à memória liberada pode expor seu conteúdo e permitir execução de código sem autenticação, com as permissões do processo web. A exploração exige que as requisições envolvidas cheguem ao mesmo worker.
Casos de uso afetados
No Apache com mod_php e PHP 8.5, um erro fatal com fatal_error_backtraces habilitado pode deixar referências ao rastreamento de chamadas. Uma configuração aplicada por requisição que produza um aviso pode acessar essas referências na requisição seguinte. O comunicado confirma execução remota de código por esse caminho.
O acompanhamento de uploads por sessão pode acessar estruturas preservadas após uma interrupção fatal. O recurso vem habilitado por padrão e funciona mesmo sem uma chamada da aplicação a session_start(). A execução de código foi demonstrada no mod_php e no PHP-FPM. No PHP-FPM, o caso validado exige uma ação da aplicação após a inicialização bem-sucedida da requisição.
Uma instalação com PHP-FPM também precisa de revisão quando o servidor encaminha PHP_VALUE ou PHP_ADMIN_VALUE que geram diagnósticos antes da inicialização da requisição. As configurações do pool e o arquivo .user.ini são aplicados em outros momentos e não constituem esse mesmo caminho de acesso antecipado.
Confira na sua instância
Confira a versão carregada pelo Apache ou pelo PHP-FPM que atende ao site, pois o resultado de php -v pode corresponder a outro executável. No Apache, revise o .htaccess e as diretivas php_value, php_flag e php_admin_* à procura de valores inválidos ou obsoletos. No servidor que encaminha requisições ao PHP-FPM, examine PHP_VALUE e PHP_ADMIN_VALUE. Confira também session.upload_progress.enabled e, no PHP 8.5, fatal_error_backtraces. Durante uma auditoria isolada, use error_reporting=E_ALL com log_errors=On e um error_log funcional para observar diagnósticos de inicialização, erros fatais e avisos durante o encerramento. Atualize para a versão corrigida da sua linha, reinicie todos os workers e confirme a versão efetivamente carregada pelo serviço.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
8.2
< 8.2.35
8.2.35
8.3
< 8.3.36
8.3.36
8.4
< 8.4.27
8.4.27
8.5
< 8.5.12
8.5.12
CVE-2026-109619. Enquanto a atualização estiver pendente, definir administrativamente fatal_error_backtraces=0 no PHP 8.5 e session.upload_progress.enabled=0, seguido do reinício de todos os workers, desativa os caminhos específicos descritos no aviso. Esses ajustes não abrangem todas as estruturas afetadas. Ocultar mensagens de erro não evita o acesso à memória liberada, e a ausência de mensagens nos logs não comprova que o servidor está protegido.
Gravidade críticaCVSS: 9,2/10Correção disponível
Esgotamento de memória deixa estruturas inválidas no encerramento da requisição
Quando uma alocação de memória falha, o PHP usa longjmp() para interromper o processamento. Algumas etapas deixam estruturas acessíveis antes de concluir sua inicialização e não corrigem esse estado quando a interrupção acontece. A rotina de encerramento pode então acessar essas estruturas inválidas e permitir execução de código sem autenticação. O comunicado demonstra a exploração no Apache com mod_php durante o processamento automático do corpo da requisição, antes da execução do código da aplicação. A correção substitui esse tratamento por uma interrupção em ponto seguro da máquina virtual ou pelo encerramento imediato do processo ao atingir um segundo limite de memória.
Casos de uso afetados
Um site atendido pelo Apache com mod_php pode receber um formulário multipart que esgote a memória durante a inicialização da requisição. O Apache executa o encerramento mesmo após essa falha, permitindo o acesso às estruturas inválidas. A exploração foi validada com limites padrão de entrada e memória.
Os limites de upload podem permitir um consumo de memória maior que o tamanho aparente da requisição. Muitos cabeçalhos dentro de uma parte multipart ampliam esse consumo. Campos de arquivo vazios também geram estruturas internas, embora não sejam incluídos em max_file_uploads. Uma requisição sem tamanho declarado utilizável pode ultrapassar a conferência inicial de post_max_size.
No PHP-FPM, uma falha durante a inicialização encerra o processo filho e evita o caminho demonstrado no mod_php. O esgotamento de memória durante a execução posterior da aplicação ainda pode alcançar estruturas inválidas. O aviso aponta suscetibilidade pela análise do código, mas não apresenta exploração completa validada para o PHP-FPM.
Confira na sua instância
Identifique se o seu site usa mod_php, PHP-FPM ou outra integração e confira a versão carregada nesse serviço. Revise o memory_limit efetivo, incluindo alterações por diretório ou pela aplicação. No servidor ou proxy que recebe as requisições, confira se há um limite para o tamanho do corpo após a decodificação, além de post_max_size no PHP. Examine também max_input_nesting_level e os limites para variáveis de entrada e partes multipart. Atualize o PHP para a correção da linha instalada, reinicie os processos e teste os formulários e uploads legítimos em homologação. Durante essa conferência, observe erros de memória e encerramentos inesperados nos logs do serviço.
Versões afetadas e correções
Faixas declaradas no comunicado oficial, por linha de manutenção
Linha
Afetadas
Corrigidas
8.2
< 8.2.35
8.2.35
8.3
< 8.3.36
8.3.36
8.4
< 8.4.27
8.4.27
8.5
< 8.5.12
8.5.12
CVE-2026-109618. O ajuste temporário memory_limit=-1 remove o limite de memória por requisição usado na exploração confirmada, mas deixa esse consumo sem limite no PHP e não cobre falhas de alocação do sistema. Sua aplicação exige reiniciar todos os workers e conferir se nenhuma configuração restaura um limite finito. Não use RLIMIT_AS ou RLIMIT_DATA como substitutos, pois eles podem provocar a falha de alocação que aciona o caminho vulnerável. Limites de container ou cgroup também não substituem a atualização. O aviso considera o FrankenPHP provavelmente suscetível pela análise do código e aponta caminhos dependentes da aplicação no LSAPI, ainda sem validação de exploração.
Programador há mais de 20 anos, fundador da Powertic e da Promovaweb. Embaixador do n8n no Brasil e da Baserow, Chatwoot, Miro e Kestra. Membro do Product Team do Mautic.
Canais oficiais
Nossos Links
Encontre a Promovaweb no canal que combina com o seu próximo passo.
