> ## Content Index > Fetch the complete content index at: https://blog.quimerax.com/llms.txt > Use this file to discover other available public pages before exploring further. # PHP em risco: duas vulnerabilidades críticas e as hipóteses de exploração - URL: https://blog.quimerax.com/php-em-risco-duas-vulnerabilidades-criticas-e-as-hipoteses-de-exploracao/ - Published: 2026-10-21T02:38:21.000Z - Updated: 2026-10-21T19:11:17.000Z - Author: Berg 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**](https://yokai.hakaisecurity.io/?ref=blog.quimerax.com), da [**Hakai**](https://hakaisecurity.io/?ref=blog.quimerax.com), acompanham a divulgação, a análise técnica das vulnerabilidades e seus possíveis impactos sobre ambientes expostos à internet. ## O que foi confirmado ![](https://blog.quimerax.com/content/images/2026/10/2026-10-20_23-08-2.png) O [advisory oficial do PHP](https://www.php.net/archive/2026.php?ref=blog.quimerax.com) 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](https://www.php.net/archive/2026.php?ref=blog.quimerax.com) 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](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp?ref=blog.quimerax.com) 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**](https://yokai.hakaisecurity.io/?ref=blog.quimerax.com) 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ão do PHP | Primeira versão corrigida | | ------------- | ------------------------- | | 8.2 | **8.2.35** | | 8.3 | **8.3.36** | | 8.4 | **8.4.27** | | 8.5 | **8.5.12** | 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 ![](https://blog.quimerax.com/content/images/2026/10/2026-10-20_23-08.png) 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**](https://hakaisecurity.io/?ref=blog.quimerax.com) 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/**](https://quimerax.com/?ref=blog.quimerax.com)**.**