CVE-2026-109619 em PHP: estado global reutilizado, sessões e execução de código

Publicado em 2026-10-27 por frfrand

Análise prática da CVE-2026-109619: o que falha nos workers PHP, versões corrigidas, mitigação temporária oficial e como atualizar.

Um erro diferente, publicado no mesmo dia

Em 21 de outubro de 2026, o PHP publicou uma segunda vulnerabilidade crítica: CVE-2026-109619. Diferentemente da falha de memória OOM do caso CVE-2026-109618, aqui o problema está relacionado a estado interno que sobrevive indevidamente após a liberação de memória. Isso pode fazer com que um worker PHP reutilize referências que não são mais válidas e, sob condições específicas, permita corrupção de memória ou execução remota de código.

O que é um worker PHP e por que isso importa?

Um worker é um processo que atende solicitações. Muitos ambientes o reutilizam para responder a visitantes sucessivos. O aplicativo deve deixar o estado correto entre uma solicitação e outra, e o mecanismo deve limpar referências temporárias. Se algo continuar apontando para memória liberada, pode ocorrer um fenômeno chamado use-after-free.

Como foi descoberto e a quem corresponde o relatório?

A investigação foi apresentada por Wiz Research e a equipe PHP, junto com o outro CVE de outubro de 2026. Os pesquisadores examinaram como certos erros de execução podiam interromper a limpeza de dados internos e deixar um estado reutilizável de forma perigosa. A divulgação coordenada permite que o público conheça o falha junto às versões corrigidas.

Como pode ser explorado?

O cenário geral envolve conduzir o processamento de requisições para erros que deixem o estado interno inconsistente. Uma operação subsequente pode utilizar referências a memória já liberada. Em condições favoráveis a um atacante, isso poderia facilitar a execução de código ou a exposição de dados do processo. A exploração varia de acordo com mod_php, PHP-FPM, o tipo de aplicação e sua configuração. Não deve ser divulgado um procedimento reutilizável para comprometer servidores; para a defesa, importam o patch e as condições de exposição.

Por que é um problema crítico?

Um processo PHP pode ter acesso a arquivos, segredos de conexão e operações internas da aplicação. Executar código com essas permissões pode ser suficiente para causar danos significativos. Porém, a classificação crítica não implica que todas as instalações possam ser exploradas da mesma forma: há dependências de configuração e características do servidor.

Quais versões precisam ser atualizadas?

Os patches do projeto PHP são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. As versões 8.1 e anteriores não recebem patches regulares do projeto; consulte provedores de manutenção estendida ou planeje a migração. Algumas distribuições Linux podem conter correções retroportadas sob um número de versão que parece anterior, portanto, verifique o boletim do pacote instalado.

Quais mitigações temporárias o PHP publicou?

A equipe recomendou desabilitar session.upload_progress.enabled antes do processamento de solicitações e reiniciar todos os workers para bloquear rotas confirmadas relacionadas a sessões. Em PHP 8.5, também mencionou fatal_error_backtraces=0 como medida para outra rota conhecida. São defesas parciais e condicionadas: o próprio fornecedor adverte que não substituem a instalação do patch. No comunicado de 23 de outubro, descreveu, além disso, um cenário muito incomum de mudanças dinâmicas do serializador de sessões relacionado a outra investigação posterior, o que lembra que as configurações importam.

Como revisar uma aplicação?

Inventarie a versão do PHP, tipo de servidor, configuração de sessões, uso de uploads e processos que não foram reiniciados após a aplicação de mudanças. Se houver suspeita de exploração, revise logs e processos, privilégios do usuário web, alterações de arquivos e credenciais que puderam ficar acessíveis. Guarde evidências antes de fazer uma limpeza indiscriminada.

Perguntas rápidas

Afecta o WordPress? Pode afetar um WordPress servido por um PHP vulnerável: é um defeito de runtime, não do tema.

Mudar a senha resolve isso? Não, embora possa ser parte de uma resposta a incidentes.

O que faço hoje? Atualize todos os runtimes que servem tráfego, reinicialize os workers e verifique as versões executadas.

Fontes: Avisos PHP outubro 2026 · Boletim do NCSC britânico · CVE da Red Hat · Registro CVE.

Onde a informação é atualizada e como solicitar orientação?

Em ArduMaker — CVE e suporte mantemos informações para revisar incidentes e canalizar consultas, especialmente em WordPress e nas tecnologias que o executam. Para avaliar um caso concreto, informe tecnologia, versão, sistema operacional, modo de implantação e mensagens de erro relevantes sem publicar credenciais. Um CVE anunciado não significa que todos os sistemas estejam comprometidos.

Revisão editorial: 27 de outubro de 2026. As recomendações podem mudar com novas publicações do fabricante.

Exemplo prático: verificar a configuração de sessões PHP

Situação: um site PHP utiliza sessões e upload de arquivos, com PHP-FPM atendendo várias requisições em cada processo. CVE-2026-109619 está relacionado a referências internas que sobrevivem indevidamente entre solicitações.

Primeiro identifique a configuração efetiva do serviço, não apenas do console. Como orientação inicial:

php --ini
php -i | grep -E 'session.upload_progress.enabled|PHP Version'

Atenção: a configuração CLI pode diferir do Apache e do PHP-FPM. O boletim do PHP descreve desativar session.upload_progress.enabled e reiniciar os workers como medida temporária para rotas conhecidas. Não o considere um patch completo.

Antes: uma alteração isolada em php.ini que nunca foi aplicada aos workers e uma versão vulnerável. Depois: versão corrigida, configuração FPM verificada, serviço reiniciado e testes de login/upload de arquivos.

Exemplo de impacto: se um worker reutilizar estado interno inválido, uma requisição subsequente poderia interagir com memória liberada. Esse é um erro do runtime, não um cookie do usuário «mal escrito».