PHP em risco: duas vulnerabilidades críticas e as hipóteses de exploração

Na noite de 20 de outubro de 2026, a equipe de segurança do PHP anunciou uma atualização emergencial para corrigir duas vulnerabilidades críticas, ambas com CVSS v4.0 9,2. Naquele momento, as causas, os componentes afetados e os detalhes de exploração ainda não haviam sido divulgados.

Em 21 de outubro, o projeto publicou as correções e confirmou que CVE-2026-109618 e CVE-2026-109619 podem permitir execução remota de código (RCE) sem autenticação, em determinadas condições. As falhas ficaram conhecidas como PHP2Shell.

A equipe de Cyber Threat Intelligence (CTI) do QuimeraX e a Yokai Research, da Hakai, acompanham a divulgação, a análise técnica das vulnerabilidades e seus possíveis impactos sobre ambientes expostos à internet.

O que foi confirmado

O advisory oficial do PHP confirma que as duas vulnerabilidades estão no núcleo da linguagem, e não em uma aplicação ou framework específico.

O problema está relacionado ao gerenciamento de memória durante o processamento de requisições, especialmente quando ocorrem falhas fatais ou condições de esgotamento de memória (out-of-memory, OOM).

Em determinadas situações, o PHP pode encerrar uma operação deixando estruturas internas em estado inconsistente. Esses dados podem continuar acessíveis depois que a memória foi liberada, permitindo corrupção de memória e, em cenários exploráveis, execução de código.

O impacto não depende necessariamente de uma vulnerabilidade no WordPress, Drupal, Joomla ou Laravel. Mesmo aplicações com código seguro podem estar expostas se executarem uma versão vulnerável do PHP.

O risco também não está restrito a uma única configuração. Ambientes que utilizam PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed precisam ser avaliados.

O cenário de maior risco demonstrado até o momento envolve o Apache com mod_php, no qual uma requisição não autenticada pode alcançar o código vulnerável antes mesmo da execução da aplicação.

CVE-2026-109618: corrupção de memória durante OOM

O advisory oficial do PHP confirma que as duas vulnerabilidades estão no núcleo da linguagem, e não em uma aplicação ou framework específico.

O problema está relacionado ao gerenciamento de memória durante o processamento de requisições, especialmente quando ocorrem falhas fatais ou condições de esgotamento de memória (out-of-memory, OOM).

Em determinadas situações, o PHP pode encerrar uma operação deixando estruturas internas em estado inconsistente. Esses dados podem continuar acessíveis depois que a memória foi liberada, permitindo corrupção de memória e, em cenários exploráveis, execução de código.

O impacto não depende necessariamente de uma vulnerabilidade no WordPress, Drupal, Joomla ou Laravel. Mesmo aplicações com código seguro podem estar expostas se executarem uma versão vulnerável do PHP.

O risco também não está restrito a uma única configuração. Ambientes que utilizam PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed precisam ser avaliados.

O cenário de maior risco demonstrado até o momento envolve o Apache com mod_php, no qual uma requisição não autenticada pode alcançar o código vulnerável antes mesmo da execução da aplicação.

CVE-2026-109619: estado global persistente entre requisições

A CVE-2026-109619 foi classificada como RCE via stale global state.

O PHP mantém estruturas internas utilizadas por diferentes etapas do processamento, incluindo informações de sessões, erros, objetos e extensões.

Essas estruturas precisam ser devidamente reinicializadas entre requisições. Entretanto, uma falha fatal pode interromper esse processo e deixar referências apontando para regiões de memória que já foram liberadas.

Quando o mesmo processo (worker) recebe outra requisição, determinadas operações podem acessar essas referências antes que a inicialização normal tenha ocorrido.

O resultado é uma condição de use-after-free, que pode ser utilizada para corrupção de memória e execução remota de código.

Para que a exploração aconteça, duas operações precisam se combinar. A primeira deixa uma referência inválida armazenada em uma estrutura persistente. A segunda, executada em outra requisição atendida pelo mesmo worker, utiliza essa referência antes que ela seja devidamente reinicializada.

O advisory confirma diferentes caminhos para essa condição, incluindo operações relacionadas a sessões e diagnósticos de configuração executados antes da inicialização normal da requisição.

No PHP 8.5, também foram identificadas condições envolvendo o armazenamento de informações de backtrace durante erros fatais.

A hipótese do session upload progress

Antes da divulgação oficial, a análise da Yokai Research apontava o mecanismo de session upload progress como um possível componente relacionado às falhas.

A divulgação confirmou que esse recurso participa de caminhos de exploração, mas também revelou que o problema é mais abrangente do que a hipótese inicial.

O recurso, presente desde o PHP 5.4 e habilitado por padrão, processa informações de uploads multipart/form-data antes da inicialização normal da aplicação.

Durante esse processamento, a extensão de sessão pode acessar estruturas internas que permaneceram referenciadas após uma interrupção anterior.

Se uma requisição deixar essas referências em estado inconsistente e outra requisição for atendida pelo mesmo worker, o processamento antecipado do progresso de upload pode alcançar memória já liberada.

Essa condição permite construir cadeias de exploração envolvendo corrupção de memória e, dependendo das características do ambiente, execução remota de código.

Portanto, o session.upload_progress é um dos caminhos confirmados, mas desabilitá-lo não elimina todas as possibilidades de exploração.

Exploração e provas de conceito

Com a divulgação técnica de 21 de outubro, foram apresentados cenários funcionais de exploração das vulnerabilidades, incluindo execução remota de código sem autenticação em ambientes que utilizam aplicações web populares.

Também foram demonstradas condições que permitem acesso indevido à memória do processo PHP. Dependendo do conteúdo presente nessas regiões, isso pode expor informações sensíveis, como credenciais, tokens de autenticação, chaves de API e outros dados processados pelo servidor.

A exploração não se resume ao envio de uma única requisição maliciosa em todos os cenários.

Algumas cadeias exigem a combinação de diferentes condições, incluindo preparação do estado interno, corrupção ou reutilização de memória e execução de operações específicas em requisições posteriores.

A complexidade técnica é relevante. Os advisories classificam as duas falhas com Attack Complexity: High e Attack Requirements: Present, conforme o CVSS v4.0.

Entretanto, a existência de cadeias funcionais demonstra que essas condições podem ser alcançadas em ambientes reais.

Com a publicação das correções e a disponibilidade dos detalhes técnicos, também aumenta a possibilidade de adaptação de exploits para diferentes versões e configurações.

Versões afetadas e correções

As correções oficiais foram disponibilizadas em 21 de outubro de 2026.

Versões anteriores a essas correções, dentro de cada versão, devem ser consideradas vulneráveis.

As falhas também possuem implicações para versões históricas do PHP. Há caminhos vulneráveis presentes em versões antigas, incluindo implementações que remontam ao PHP 5.4.

As versões 8.1 e anteriores estão fora do suporte regular do projeto. Para ambientes legados, foram disponibilizados backports de código-fonte para 7.4, 8.0 e 8.1, enquanto fornecedores de distribuições Linux e serviços de suporte estendido podem disponibilizar pacotes próprios com as correções.

É importante considerar que a versão exibida pelo gerenciador de pacotes nem sempre corresponde diretamente à versão original em que uma correção foi introduzida. Distribuições podem aplicar backports de segurança sem alterar o número principal da versão instalada.

Por isso, a validação deve considerar os avisos do fornecedor e o pacote efetivamente utilizado pelo serviço.

A atualização do núcleo do PHP é necessária. Atualizar apenas o WordPress, Drupal ou outro framework não resolve o problema.

Mitigação e monitoramento

O projeto PHP é explícito ao afirmar que a atualização é a única correção completa.

Para ambientes que não podem ser atualizados imediatamente, o advisory apresenta medidas temporárias para reduzir a exposição a determinados caminhos de exploração.

CVE-2026-109618

Uma das recomendações é configurar memory_limit=-1, impedindo que o limite de memória do próprio PHP provoque a interrupção explorada na cadeia demonstrada.

Essa mudança não elimina outras possibilidades de falha de alocação e exige cuidado com o consumo de recursos do servidor, já que remove o limite de memória por requisição imposto pelo PHP.

Também são recomendados controles mais restritivos para requisições multipart, incluindo limites para tamanho do corpo, quantidade de campos, cabeçalhos e profundidade de estruturas.

Quando a aplicação não necessita de uploads ou formulários multipart, esse tipo de requisição pode ser bloqueado antes de chegar ao PHP.

Esses controles reduzem a superfície de ataque, mas não substituem a correção.

CVE-2026-109619

Desabilitar session.upload_progress.enabled bloqueia caminhos confirmados envolvendo o processamento antecipado de sessões.

Em ambientes PHP 8.5, desabilitar fatal_error_backtraces também reduz a exposição a uma das cadeias demonstradas.

Outra recomendação é revisar configurações inválidas ou obsoletas que provoquem avisos durante a inicialização de requisições. Esses avisos podem participar das condições necessárias para acessar referências inválidas.

Ocultar mensagens com display_errors, error_reporting ou mecanismos semelhantes não elimina a vulnerabilidade, pois o acesso ao estado interno pode acontecer antes da decisão de exibir ou registrar o erro.

As medidas devem ser aplicadas na configuração efetivamente utilizada pelo serviço, com reinicialização dos workers quando necessário.

Nenhuma dessas alterações deve ser tratada como substituta da atualização.

Detecção

Do ponto de vista de monitoramento, alguns comportamentos podem ajudar a identificar tentativas de exploração ou atividades que merecem investigação.

Entre eles estão requisições multipart/form-data incomuns, erros recorrentes de esgotamento de memória, respostas HTTP 500 em sequência, encerramentos inesperados de processos PHP e anomalias relacionadas ao gerenciamento de sessões.

Cookies PHPSESSID com conteúdo ou tamanho fora do comportamento esperado também podem ser relevantes em determinadas cadeias de exploração.

Esses sinais devem ser correlacionados com a versão do PHP, a configuração do serviço e os registros de aplicação e infraestrutura.

A presença isolada desses indicadores não comprova exploração, mas pode justificar uma análise mais aprofundada, principalmente em ambientes que ainda não receberam a atualização.

No cliente

O QuimeraX reduz o tempo entre a divulgação de uma vulnerabilidade e a identificação dos ativos potencialmente afetados.

O EASM mantém o mapeamento de domínios, aplicações e serviços expostos à internet. A partir dessa superfície, o time da Hakai trabalha na integração de templates de detecção ao motor de ASM, permitindo identificar ativos PHP que precisam de validação e correção.

O contexto produzido pela equipe de CTI é incorporado à mesma plataforma, relacionando as informações técnicas da vulnerabilidade com os ativos monitorados e as medidas recomendadas.

O objetivo é que o cliente saiba onde priorizar a atualização, quais exposições precisam ser investigadas e quais ações podem reduzir o risco enquanto a correção é aplicada.

Agende uma demonstração da plataforma em https://quimerax.com/.