Falhas críticas no PHP mobilizam empresas e expõem desafio de encontrar instalações fora do radar da TI.

Duas vulnerabilidades críticas no PHP, tecnologia utilizada no funcionamento de sites e aplicações corporativas, colocaram equipes de tecnologia e segurança em alerta nesta semana. Identificadas como CVE-2026-109618 e CVE-2026-109619 e apelidadas de PHP2Shell, as falhas podem permitir que invasores executem código remotamente, sem autenticação, por meio de requisições web especialmente elaboradas. As correções foram disponibilizadas em 21 de outubro.

Já há relatos de sites de prefeituras e órgãos públicos que ficaram fora do ar por conta dessa vulnerabilidade. Recomendação é que você mude senha, principalmente se você usa uma única para vários serviços. Já para empresários e profissionais do TI a atenção deve ser redobrada, principalmente em instalações “escondidas”. Donos e gestores de sites que usam essa tecnologia também devem ficar atentos.

O problema está no núcleo do PHP, e não em um plugin ou aplicação específica. As duas vulnerabilidades receberam pontuação de 9,2 no sistema de classificação de gravidade CVSS v4.0. O comunicado oficial do projeto recomenda atualização imediata e aponta instalações do Apache com mod_php como as de maior risco, com exploração demonstrada antes mesmo da execução do código da aplicação.

A primeira falha envolve corrupção de memória durante o processamento de requisições, incluindo aquelas utilizadas no envio de arquivos. A segunda permite que uma requisição posterior utilize informações internas associadas a uma memória já liberada. Na prática, esses comportamentos podem abrir caminho para a execução de código malicioso em instalações vulneráveis.

O desafio começa antes da correção.

Embora as atualizações já estejam disponíveis, localizar todos os ambientes que precisam recebê-las pode ser a etapa mais difícil da resposta. Em análise publicada sobre o caso, a Tanium destaca que o PHP pode estar presente em servidores, contêineres, ferramentas de desenvolvimento e aplicações de terceiros, inclusive em estações de trabalho.

No Windows, por exemplo, a tecnologia pode ser distribuída em uma pasta ou incorporada a outro software sem aparecer na lista de programas instalados. Em aplicações que incluem sua própria cópia do PHP, atualizar apenas os pacotes do sistema operacional pode deixar a versão vulnerável intacta.

Essa dispersão exige que as empresas combinem inventário de software, identificação de arquivos e análise dos processos em execução. Também é necessário diferenciar uma instalação existente no equipamento de um serviço que efetivamente recebe requisições pela internet, condição que influencia a prioridade da resposta.

Tentativas de exploração aumentam a urgência.

Segundo a análise da Tanium, publicada em 21 de outubro, já haviam sido relatadas tentativas de exploração em ambientes de monitoramento. A viabilidade dos ataques varia conforme a configuração e a plataforma, mas essa diferença não elimina a necessidade de corrigir as instalações afetadas.

A orientação é priorizar serviços expostos à internet, especialmente ambientes com mod_php e sistemas ARM64. A investigação também deve considerar registros recentes dos servidores, procurando encerramentos inesperados de processos e requisições de upload incomuns. Esses eventos precisam ser analisados em contexto, pois, isoladamente, não comprovam uma invasão.

Para apoiar o levantamento, a Tanium informa que seu conteúdo do Guardian para PHP2Shell combina sensores de aplicações instaladas, identificação de cópias do PHP no Windows e detecção de processos em execução. O objetivo é ajudar as equipes a localizar instalações que poderiam escapar de um inventário convencional e direcionar as correções.

Atualizar e comprovar a aplicação.

As versões corrigidas são PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Empresas que utilizam pacotes mantidos por distribuições Linux ou fornecedores de aplicações devem verificar os respectivos comunicados, já que a correção pode ser incorporada ao pacote sem seguir a mesma numeração das versões oficiais do projeto.

Após a atualização, é necessário reiniciar os processos pertinentes para que o código corrigido seja carregado. Quando a aplicação imediata não for possível, restringir a exposição dos serviços pode reduzir o risco temporariamente. O projeto PHP ressalta, porém, que medidas parciais de mitigação não substituem a atualização.

Para as empresas, a resposta ao PHP2Shell depende de fechar todo o ciclo: descobrir onde a tecnologia está presente, identificar os ambientes mais expostos, aplicar as correções e verificar se as instâncias em execução passaram a utilizar o código atualizado.