Falhas críticas em PHP forçam corrida global por atualização

Segurança Digital

Correções urgentes no PHP visam proteger sistemas contra vulnerabilidades graves exploradas globalmente.

Leia também: Gemini 4 Argon benchmark mostra rapidez, mas falha no uso real

Atualizações emergenciais do PHP liberadas em 21 de outubro corrigem duas vulnerabilidades críticas de execução remota de código, apelidadas de php2shell, que afetam praticamente todas as versões da linguagem desde a 5.4 e já estão sendo exploradas na internet, levando empresas, governos e provedores a correr para aplicar patches e até desligar servidores preventivamente.

Falhas permitem execução remota sem login

As correções estão nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 do PHP e fecham as brechas catalogadas como CVE-2026-109618 e CVE-2026-109619, ambas com pontuação 9,2 no sistema CVSS v4.0. As duas são falhas de segurança de memória no ciclo de vida das requisições: uma ligada ao tratamento de falta de memória (out-of-memory) e outra a um estado interno que continua existindo depois de a memória que o suportava ser liberada.

Na prática, em configurações amplamente usadas de servidor web, essas falhas permitem que um atacante execute código arbitrário de forma remota, sem autenticação, enviando requisições HTTP especialmente construídas para servidores vulneráveis. A Fundação PHP foi direta ao orientar administradores: “There are no complete mitigations; updating is the only safe choice.”

A exposição depende de como o PHP é servido. Em servidores Apache com mod_php, pesquisadores confirmaram execução remota de código pelas duas vulnerabilidades usando configurações padrão de limites de memória e entrada. No PHP-FPM, a falha ligada ao ciclo de vida de sessões foi validada, mas ainda não há demonstração pública de exploit completo para o bug de falta de memória. Implementações alternativas como FrankenPHP são consideradas provavelmente vulneráveis com base na análise de código.

Ataques começaram antes do patch

Dados de telemetria de ameaças mostram que as tentativas de exploração começaram antes da liberação oficial das correções. A equipe de inteligência de ameaças da Amazon identificou “an exploitation attempt dating to October 17 in MadPot telemetry, originating from an IP address associated with a commercial anonymization network.” Clientes foram orientados a investigar acessos suspeitos a partir dessa data.

A Cloudflare, por sua vez, passou a bloquear tentativas de exploração com regras específicas em seu firewall de aplicação (WAF) ainda no dia 21 de outubro, cerca de nove horas antes da publicação dos patches pela equipe do PHP.

A divulgação coordenada das falhas naufragou nos dias anteriores ao lançamento. A Fundação PHP relata que os identificadores dos CVEs começaram a circular antes do tempo previsto, um pesquisador publicou por engano um vídeo com prova de conceito, e “Chainguard unilaterally broke the embargo and published built images containing the fix.” Com isso, atacantes puderam estudar o comportamento da correção e deduzir o problema original enquanto milhões de servidores permaneciam sem atualização.

Sites fora do ar e corrida por atualizações

O vazamento de detalhes técnicos e a perspectiva de exploits funcionais fizeram muitos operadores optarem por medidas drásticas. Em fóruns técnicos, o usuário iamShorteh relatou ter desligado todos os seus sites: “Somebody leaked the step by step for RCE on twitter a few hours ago. Not going to risk sitting around another 5-6 hours until the hotfix lands.”

Órgãos públicos também reagiram. O Centro Nacional de Segurança Cibernética da Holanda tirou seu site do ar por precaução, assim como a Câmara dos Deputados holandesa, numa tentativa de eliminar qualquer superfície de ataque até que as correções estivessem disponíveis e testadas.

Entre provedores de hospedagem, empresas de comércio eletrônico e órgãos governamentais, o movimento foi parecido: priorizar a aplicação de patches, aceitar janelas de indisponibilidade e, em cenários mais sensíveis, isolar ou desligar temporariamente serviços baseados em PHP.

Distribuições Linux correm em ritmos diferentes

Depois do anúncio, o foco de administradores migrou rapidamente para os repositórios de suas distribuições Linux. Pacotes atualizados chegaram em velocidades distintas. Versões recentes do Debian, como o Trixie, incorporaram os patches rapidamente, enquanto Ubuntu, Red Hat e imagens oficiais no Docker Hub demoraram mais a disponibilizar builds com as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

O mantenedor Ondřej Surý, responsável por repositórios populares de PHP, recebeu elogios de desenvolvedores e operadores pela agilidade e suporte, mas seus servidores sofreram sobrecarga devido ao volume de downloads, o que empurrou alguns usuários para espelhos alternativos e para a compilação manual de imagens a partir de Dockerfiles já corrigidos.

A desigualdade no ritmo de atualização aumentou a pressão sobre equipes de TI em empresas e órgãos públicos, especialmente em ambientes complexos, com múltiplos containers, diferentes versões de PHP e aplicações legadas.

Descobrir onde o PHP estava virou desafio

Um dos problemas práticos mais relatados nas primeiras horas após o alerta foi simplesmente descobrir em quais sistemas o PHP estava sendo usado. Em muitos ambientes, a linguagem está embutida em ferramentas como painéis de gestão de rede, plataformas de armazenamento, suítes colaborativas e orquestradores de containers, sem indicação óbvia para o administrador.

Em fóruns, usuários citaram ter encontrado instâncias de PHP em soluções como firewalls baseados em OPNsense, sistemas como OpenMediaVault, instalações do Nextcloud e gerenciadores como o Coolify. Para parte dos operadores de laboratório doméstico e pequenas empresas, a adoção intensiva de containers escondeu a pilha tecnológica real dos serviços. Isso atrasou a resposta e aumentou o risco de algum servidor vulnerável passar despercebido.

Como saber se o servidor está realmente corrigido?

Não basta instalar o pacote atualizado para ter certeza de que o servidor não está mais vulnerável às falhas php2shell. Em muitos casos, versões antigas do motor PHP continuam carregadas em memória por processos de servidor web ou de PHP-FPM, mesmo depois da atualização dos binários no disco.

Especialistas destacam que confiar apenas na saída do comando php -v é insuficiente, porque ela reflete o binário da linha de comando, não necessariamente a versão usada pelo servidor web. Em distribuições que fazem backport de correções de segurança, o número de versão exibido pode nem mudar, exigindo verificação do número completo do pacote nos rastreadores da própria distro.

Além disso, workers de Apache e processos do PHP-FPM precisam ser reiniciados após a atualização para carregar o novo código em memória. Os comunicados oficiais do PHP enfatizam que toda a cadeia de serviços que executa scripts PHP deve ser reiniciada como parte do procedimento de mitigação.

Exploração não é trivial, mas risco continua alto

Embora as duas vulnerabilidades tenham pontuação alta e permitam execução remota de código, os próprios boletins técnicos classificam a complexidade de ataque como elevada, com requisitos adicionais para que o exploit funcione. Testes independentes indicam que muitos códigos de exploração publicados não funcionam em instalações padrão (“vanilla”) do PHP.

O usuário SirRobinBlibs, que compilou relatos de administradores durante a corrida por atualizações, alertou para o uso irresponsável de provas de conceito disponíveis em repositórios públicos: “Most of the starred ones don’t work on vanilla PHP, and malicious PoC repos are a known thing.” Pesquisas paralelas identificaram inclusive códigos falsos usados como pegadinhas, como um que altera o papel de parede da vítima.

Ainda assim, a combinação de falha crítica, tentativas de exploração já observadas em redes de anonimização comerciais e exposição massiva de servidores que ainda não foram atualizados mantém o nível de alerta elevado. A expectativa de especialistas é de um aumento na vigilância, com mais regras em firewalls de aplicação, monitoramento de logs e revisão de configurações de PHP em grandes infraestruturas.

Dependência da comunidade e próximos passos

A Fundação PHP reconhece que o trabalho de segurança da linguagem ainda se apoia em um grupo pequeno de desenvolvedores financiados pela própria fundação e por contribuições da comunidade. O caso php2shell expôs fragilidades na coordenação de divulgação, com vazamento antecipado de identificadores de falha, publicação acidental de prova de conceito e quebra de embargo por uma fornecedora de imagens de container.

Pesquisadores e mantenedores defendem processos mais robustos de divulgação coordenada, maior participação de grandes provedores e nuvens comerciais e mais recursos dedicados à segurança de uma linguagem que ainda sustenta boa parte da web. Ao mesmo tempo, reforçam a orientação imediata: aplicar as versões 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, reiniciar todos os serviços que usam PHP e tratar com cautela qualquer código de exploração disponível publicamente.