CVE-2026-109618 e 109619 no PHP: como corrigir

Resposta rápida

Se um servidor atende requisições web com PHP 8.2 anterior a 8.2.35, 8.3 anterior a 8.3.36, 8.4 anterior a 8.4.27 ou 8.5 anterior a 8.5.12, atualize imediatamente para a versão corrigida da mesma linha ou para uma linha posterior compatível. As CVE-2026-109618 e CVE-2026-109619 são falhas críticas que podem permitir execução remota de código sem autenticação. O projeto PHP afirma que não existe mitigação completa além da atualização.

Depois de instalar o pacote ou publicar a nova imagem, reinicie todos os processos PHP, Apache e contêineres aplicáveis. Confirme a versão no runtime que realmente responde ao site: php -v no terminal pode apontar para um binário diferente do PHP-FPM, do mod_php, do LSAPI ou da imagem em produção.

Versões afetadas e corrigidas

As duas vulnerabilidades têm a mesma matriz de versões. PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12 incluem as correções. A linha 8.2 recebe somente correções críticas e chega ao fim do suporte em 31 de dezembro de 2026; use o patch agora e planeje a migração para uma linha com suporte mais longo.

PHP 8.1 e versões anteriores já encerraram o suporte do projeto. Alguns distribuidores e fornecedores LTS aplicam correções retroativas sem reproduzir o número da versão upstream. Nesse caso, valide o boletim e o pacote do fornecedor. Se não houver backport suportado, migre para uma linha mantida; não trate uma versão antiga apenas com número diferente como corrigida sem essa evidência.

• PHP 8.2: instale 8.2.35 ou posterior.
• PHP 8.3: instale 8.3.36 ou posterior.
• PHP 8.4: instale 8.4.27 ou posterior.
• PHP 8.5: instale 8.5.12 ou posterior.
• PHP 8.1 ou anterior: confirme um backport do fornecedor ou migre para uma linha suportada.

O que cada falha permite

A CVE-2026-109618 está no tratamento de falta de memória. Em determinados contextos, uma alocação que falha pode deixar a memória da requisição em estado inválido; o encerramento da requisição pode então processar esse estado. O advisory confirma que requisições multipart e outros caminhos controláveis podem provocar a condição. mod_php é o cenário confirmado de maior risco; a análise do código também considera FPM suscetível, embora o advisory não apresente um exploit completo para essa SAPI específica.

A CVE-2026-109619 envolve estado global antigo que sobrevive entre requisições depois que a memória correspondente foi liberada. Uma requisição produz o estado incorreto e outra, atendida pelo mesmo worker, o consome antes da reinicialização normal. O impacto confirmado inclui uso de memória liberada e execução de código com os privilégios do processo web.

Como inventariar o runtime real

Comece pelo caminho público de cada aplicação e identifique como o PHP é executado. Registre versão, SAPI, arquivo php.ini carregado, pacote do sistema ou digest da imagem e o pool de workers. Em hospedagem gerenciada, confira a versão no painel e no documento do provedor; em um cluster, repita a validação em todos os nós.

Use php -v e php --ini para o CLI, mas não pare neles. Compare com php-fpm -v quando disponível e com a configuração do serviço que atende a web. Uma página temporária com phpversion() ou phpinfo() pode confirmar o runtime, mas deve ficar restrita, ser removida logo depois e nunca expor configuração sensível publicamente. composer update, atualizar o WordPress ou atualizar um framework não troca o binário do PHP.

• Mapeie cada domínio, pool FPM, módulo Apache, LSAPI, contêiner e job que executa PHP.
• Registre o pacote ou digest atual e o php.ini efetivamente carregado pelo serviço web.
• Compare a versão com o patch da linha ou com o boletim de backport do fornecedor.
• Localize réplicas, workers antigos e imagens em cache que possam continuar vulneráveis.
• Planeje a atualização, o reinício completo e uma forma segura de reversão que não restaure a versão vulnerável.

Como atualizar e verificar

Em distribuições Linux, use somente o repositório e o procedimento suportados pelo fornecedor e leia o boletim do pacote. Em contêineres, reconstrua a imagem a partir de uma base corrigida, fixe ou registre o digest e substitua todas as réplicas. Em cPanel, Plesk, hospedagem compartilhada ou plataforma gerenciada, selecione a versão corrigida ou confirme por escrito que o provedor aplicou um backport.

Reinicie todos os workers após a atualização: processos antigos continuam executando o binário carregado antes da troca. Depois, valide a versão no caminho web, execute health checks e teste login, upload, sessão, formulários, filas e integrações críticas. Monitore erros 500 e 503, reinícios de workers, consumo de memória e logs do servidor durante a estabilização.

• Faça backup e confirme que o plano de reversão não aponta para uma imagem ou pacote vulnerável.
• Instale o release corrigido ou o pacote com backport documentado pelo fornecedor.
• Reinicie PHP-FPM, Apache, LSAPI ou todos os contêineres e réplicas aplicáveis.
• Confirme a versão e o SAPI no processo que atende a produção, não somente no terminal.
• Teste os fluxos essenciais e registre versão, pacote ou digest, nós validados e horário do reinício.

Mitigações temporárias não substituem o patch

Se a atualização for momentaneamente impossível, a orientação oficial para a CVE-2026-109618 inclui aplicar memory_limit=-1 em configuração administrativa, reiniciar todos os workers, limitar o tamanho decodificado das requisições na borda e manter post_max_size conservador. Essa configuração remove o caminho confirmado que depende de um limite previsível, mas outra falha de alocação ainda pode alcançar o código vulnerável. Não use RLIMIT_AS ou RLIMIT_DATA como atalho.

Para a CVE-2026-109619, desative session.upload_progress.enabled, reinicie todos os workers e, no PHP 8.5, defina fatal_error_backtraces=0. Essas medidas cobrem somente caminhos demonstrados. Se não for possível corrigir rapidamente um serviço exposto, a recomendação do CERT-EU é isolá-lo da rede pública até aplicar e verificar o patch.

Cloudflare WAF ajuda, mas a regra não é nova

A Cloudflare atualizou em 22 de outubro os nomes e metadados de sete regras existentes do Managed Ruleset para identificar as duas CVEs. O comunicado é explícito: a lógica de detecção e as ações dessas regras não mudaram. Portanto, confirme que o conjunto está implantado e que a ação esperada está ativa, mas não interprete o anúncio como uma nova correção na borda.

Um WAF reduz alguns caminhos conhecidos, mas não altera o binário do PHP, não protege acesso direto à origem e não cobre necessariamente uma variante ou rota interna. Mantenha-o como defesa adicional depois da atualização. Se o site continuar fora do ar após o patch, use o diagnóstico web para separar DNS, TLS e HTTP de uma falha do runtime ou da aplicação.

O que revisar se houver suspeita de exploração

Executar uma versão afetada demonstra exposição, não comprova invasão. Preserve logs do proxy, servidor web, PHP, contêiner e sistema antes de reiniciar ou limpar arquivos. Procure repetição incomum de requisições multipart, erros fatais, falta de memória, término de workers, arquivos ou processos inesperados e mudanças em contas, tarefas agendadas ou credenciais.

A ausência desses sinais também não prova segurança: falhas podem ocorrer antes do registro e logs podem estar incompletos. Se houver evidência de comprometimento, isole o nó, preserve uma imagem para análise, reconstrua a partir de uma base confiável já corrigida e só então rotacione segredos que o processo web poderia acessar.

Limitações e próxima ação útil

Este guia foi verificado em 23 de outubro de 2026 nas fontes oficiais do PHP, nos advisories do projeto, nos registros CVE, no CERT-EU e no comunicado da Cloudflare. Versões empacotadas por distribuições podem conter backports; o número exibido isoladamente não substitui o boletim do fornecedor. Um teste público de HTTPS também não revela com segurança a versão interna do PHP.

A próxima ação é construir uma planilha curta com domínio, SAPI, versão, pacote ou digest, fornecedor, todos os nós e responsável. Atualize primeiro os serviços expostos à internet, reinicie integralmente o pool e anexe a evidência da versão corrigida. Depois valide DNS, TLS e resposta HTTP sem tentar explorar a vulnerabilidade.

Fontes consultadas

Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.

• Security advisory: Critical remote code execution vulnerabilitiesPHP
• RCE via OOM corruptionPHP Security Advisory
• RCE via stale global statePHP Security Advisory
• CVE-2026-109618 recordCVE Program
• CVE-2026-109619 recordCVE Program
• Critical Vulnerabilities in PHPCERT-EU
• PHP Supported VersionsPHP
• Emergency WAF release for PHP RCECloudflare