This post is also available in: Português

As vulnerabilidades CVE-2026-109618 e CVE-2026-109619, conhecidas em conjunto como PHP2Shell, levaram o projeto PHP a publicar uma atualização emergencial para corrigir duas falhas críticas que podem permitir execução remota de código sem autenticação. Ambas receberam pontuação CVSS 9.2 na versão 4.0 da metodologia, indicando um nível crítico de severidade.

Em 21 de outubro de 2026, a equipe responsável pelo PHP disponibilizou correções para as versões suportadas da linguagem e recomendou a atualização imediata. O alerta ganhou ainda mais relevância após relatos de exploração ativa, reforçando a necessidade de identificar instalações vulneráveis e aplicar as correções sem demora.

O impacto potencial vai além de aplicações desenvolvidas diretamente em PHP. A linguagem é utilizada por plataformas como WordPress e por diversos sistemas corporativos, portais e serviços web. Por isso, a vulnerabilidade precisa ser avaliada no nível da infraestrutura que executa o PHP, e não apenas no código das aplicações.

O que é o PHP e por que essas vulnerabilidades preocupam tanto?

O PHP é uma das linguagens de programação mais utilizadas no desenvolvimento de aplicações web. Desde sua criação, tornou-se um dos pilares da internet moderna, sendo responsável pelo funcionamento de milhões de sites, sistemas corporativos e plataformas de comércio eletrônico.

Além de aplicações desenvolvidas sob medida, diversas soluções amplamente utilizadas dependem diretamente do PHP, incluindo WordPress, Drupal, Joomla, Magento, Laravel, MediaWiki, phpBB, WHMCS e inúmeros sistemas internos utilizados por empresas.

Quando uma vulnerabilidade afeta o núcleo da linguagem, o problema deixa de estar restrito a um plugin ou framework específico. O risco passa a atingir todo o ecossistema que utiliza aquele interpretador, ampliando significativamente a superfície de ataque.

O que aconteceu com as CVE-2026-109618 e CVE-2026-109619?

Em 20 de outubro de 2026, a equipe de segurança do PHP anunciou uma atualização emergencial para corrigir duas vulnerabilidades críticas. Antes da divulgação técnica completa, informações sobre as falhas começaram a circular publicamente, e pesquisadores de segurança passaram a investigar o potencial de exploração.

No dia 21 de outubro, o projeto PHP publicou as correções e os detalhes técnicos das vulnerabilidades. O caso, conhecido como PHP2Shell, passou a exigir atenção imediata dos administradores, especialmente em servidores que processam requisições web e podem estar expostos a ataques remotos.

A divulgação também evidenciou a importância de agir rapidamente diante de falhas críticas em componentes amplamente utilizados. Além de atualizar o PHP, as organizações precisam identificar todos os serviços afetados e avaliar possíveis sinais de comprometimento nos ambientes expostos.

Qual é o impacto das vulnerabilidades?

As informações divulgadas apontam que as duas falhas podem permitir execução remota de código sem autenticação, conhecida pela sigla RCE.

Na prática, isso significa que um invasor pode executar comandos diretamente no servidor onde o PHP está rodando, sem precisar realizar login na aplicação. Dependendo da configuração do ambiente, esse acesso pode abrir caminho para comprometimento completo do servidor, roubo de dados sensíveis, instalação de backdoors, movimentação lateral na infraestrutura e indisponibilidade dos serviços.

Por atingirem o próprio interpretador da linguagem, os impactos não se limitam a um tipo específico de aplicação. Um único servidor pode hospedar diversos sites vulneráveis simultaneamente.

CVSS 9.2: o que significa essa classificação?

O projeto PHP atribuiu CVSS v4.0 de 9.2 para ambas as vulnerabilidades. Essa pontuação enquadra as falhas como críticas porque combinam características extremamente perigosas, como exploração pela rede, ausência de necessidade de autenticação, baixa complexidade de ataque e potencial elevado de comprometimento da confidencialidade, integridade e disponibilidade dos sistemas.

Embora algumas publicações iniciais tenham mencionado uma pontuação 10.0 baseada em vazamentos preliminares, a classificação oficial divulgada pela equipe responsável pelo PHP permanece em 9.2.

Quais versões foram afetadas?

As vulnerabilidades PHP2Shell exigiram correções nas versões suportadas do PHP. O projeto disponibilizou as seguintes versões corrigidas em 21 de outubro de 2026:

A recomendação oficial é atualizar imediatamente para a versão corrigida correspondente à linha utilizada. Organizações que recebem o PHP por meio de distribuições Linux, provedores de hospedagem ou outros fornecedores devem verificar também a disponibilidade de pacotes atualizados mantidos por esses fornecedores.

O cenário merece atenção especial em ambientes legados. O PHP 8.1 e as versões anteriores já não recebem atualizações regulares de segurança diretamente do projeto. Entretanto, algumas distribuições e fornecedores com suporte estendido podem disponibilizar correções retroativas. Por isso, é necessário confirmar se existe um patch específico para a versão instalada.

Quando não houver uma correção disponível, a organização deve avaliar a migração para uma versão suportada e adotar medidas temporárias para reduzir a exposição, priorizando o isolamento de serviços vulneráveis acessíveis pela internet.

O que já se sabe sobre o mecanismo da falha?

A CVE-2026-109618 está relacionada a uma falha no tratamento de situações de esgotamento de memória, conhecidas como Out of Memory (OOM). Nesse cenário, uma interrupção durante a inicialização de estruturas internas da requisição pode fazer com que o processo de limpeza trate dados parcialmente inicializados como se fossem válidos. Sob determinadas condições, esse comportamento pode permitir execução remota de código.

Já a CVE-2026-109619 envolve o uso de estado global obsoleto após a liberação da memória associada a uma requisição. Quando esse estado permanece disponível e é reutilizado antes da reinicialização adequada das estruturas internas, o processo pode acessar dados inválidos e abrir caminho para execução arbitrária de código.

As duas falhas afetam o funcionamento interno do interpretador PHP, o que explica por que a vulnerabilidade não está restrita a um framework, plugin ou aplicação específica. O risco depende também da forma como o PHP é executado e integrado ao servidor web.

A equipe do PHP identificou o risco em diferentes configurações que atendem requisições web e destacou exposição elevada em ambientes que utilizam Apache com mod_php. Por esse motivo, a avaliação deve considerar todos os serviços e modos de execução do PHP presentes na infraestrutura.

Existe exploração ativa das vulnerabilidades PHP2Shell?

Sim. Após a divulgação inicial, pesquisadores e empresas de segurança relataram sinais de exploração ativa das vulnerabilidades PHP2Shell. Esse cenário aumenta a urgência da atualização, principalmente em servidores web acessíveis pela internet.

A existência de relatos de exploração não significa que todas as instalações vulneráveis tenham sido comprometidas. No entanto, a possibilidade de execução remota de código sem autenticação torna essencial verificar se os ambientes foram expostos e investigar eventuais sinais de atividade suspeita.

Além de aplicar as correções, as equipes de segurança devem revisar logs dos servidores web, processos executados pelo PHP, conexões de rede incomuns e alterações inesperadas nos sistemas. Caso existam indícios de comprometimento, a organização deve conduzir uma investigação de incidente e avaliar a necessidade de contenção imediata.

Como proteger seu ambiente contra PHP2Shell

A principal medida de proteção é atualizar o PHP para uma das versões corrigidas assim que possível. A atualização deve abranger todas as instalações utilizadas por aplicações web, incluindo serviços PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed.

A equipe do PHP também publicou orientações complementares para reduzir determinados caminhos de exploração. Entre elas estão o controle dos limites de tamanho das requisições e uploads, a aplicação de limites de recursos para processos e ajustes de configuração em cenários específicos. Essas medidas devem ser avaliadas conforme a arquitetura e os requisitos de cada ambiente.

A desativação de session.upload_progress.enabled pode bloquear caminhos específicos associados à CVE-2026-109619, desde que seja aplicada corretamente antes do processamento das requisições e que os processos sejam reiniciados. Entretanto, essa configuração não elimina todas as variantes de exploração e não deve ser considerada uma solução completa.

Para versões antigas sem suporte, é necessário verificar se o fornecedor disponibilizou uma correção retroativa. Caso contrário, a organização deve priorizar a migração para uma versão mantida e considerar o isolamento temporário dos serviços expostos até que seja possível corrigir o problema.

Depois da atualização, é importante confirmar a versão efetivamente carregada pelos processos, reiniciar os serviços necessários e investigar possíveis sinais de comprometimento anteriores à aplicação do patch.

O projeto PHP ressalta que não existem mitigações completas para substituir a atualização. Portanto, medidas temporárias devem ser tratadas como complementares, e não como alternativas à correção oficial.

O que as empresas devem fazer agora

O caso PHP2Shell reforça a importância de manter um processo contínuo de gestão de vulnerabilidades. Em ambientes com múltiplos servidores, aplicações legadas e dependências tecnológicas, identificar rapidamente todos os ativos afetados é fundamental para evitar que sistemas esquecidos permaneçam expostos.

Além da atualização emergencial, as organizações devem verificar as versões instaladas, acompanhar as correções disponibilizadas por fornecedores, priorizar os ativos expostos à internet e avaliar evidências de possíveis ataques. O processo precisa incluir também a validação das correções e o acompanhamento de eventuais riscos residuais.

A Gestão Continuada de Vulnerabilidades permite estruturar esse trabalho de maneira recorrente, apoiando a identificação de ativos, a análise de criticidade e a priorização das ações corretivas conforme o risco para o negócio.

Na OSTEC, acompanhamos vulnerabilidades críticas como a CVE-2026-109618 e a CVE-2026-109619 para apoiar as organizações na compreensão dos riscos e na definição de prioridades de segurança. A identificação de falhas, a avaliação de exposição e o acompanhamento das correções são etapas importantes para reduzir a superfície de ataque e fortalecer a proteção da infraestrutura digital.

Como novas informações técnicas podem surgir durante a investigação de vulnerabilidades críticas, este conteúdo poderá ser atualizado para refletir recomendações e orientações oficiais adicionais.

This post is also available in: Português

Compartilhe: