PHP2Shell: duas falhas no coração do PHP forçam atualização de emergência e tiram sites do ar pelo mundo

Às 11 da manhã desta quarta-feira (21), horário de Brasília, o projeto PHP publicou o que muita gente de TI passou a noite esperando: correções de emergência para duas falhas críticas no núcleo da linguagem — a parte que praticamente toda requisição a um site em PHP atravessa. Antes e depois do anúncio, governos e empresas tiraram sites do ar por precaução, enquanto as primeiras tentativas de ataque já apareciam nos sensores de quem vigia a internet.

O que é o PHP2Shell

As falhas são a CVE-2026-109618 e a CVE-2026-109619, apelidadas juntas de PHP2Shell, ambas com nota 9,2 na escala CVSS 4.0. As duas permitem execução remota de código sem autenticação: um visitante qualquer, sem login, pode chegar a rodar comandos no servidor.

• A primeira explora o tratamento de falta de memória: o PHP pode ser interrompido com dados internos da requisição pela metade, e a limpeza que vem depois trata esse lixo como válido.
• A segunda envolve estado que sobrevive entre requisições: um resto da requisição anterior, cuja memória já foi liberada, é usado pela seguinte no mesmo processo.

Segundo o aviso oficial, estão em risco todas as instalações que atendem requisições web — PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é maior no mod_php, para o qual há exploração demonstrada em que o ataque dispara antes de qualquer código do site rodar. Não adianta o sistema de cima ser bem escrito: o problema está embaixo dele.

Por que virou corrida

Estimativas citadas pelo The Record apontam que mais de 70% dos sites usam PHP. Um levantamento do VirusTotal contou 5,1 milhões de endereços na internet rodando a linguagem — cerca de 758 mil deles em versões que nem recebem mais atualização.

E o segredo não durou até a data marcada. O projeto havia avisado na terça-feira (20) que publicaria as correções no dia seguinte. Segundo a PHP Foundation, a empresa Calif, cuja pesquisadora reportou o problema em 11 de agosto, publicou por engano um vídeo com uma prova de conceito funcionando — apagado, mas já espalhado. E a Chainguard quebrou o embargo ao liberar imagens com a correção antes da hora, o que permite estudar o conserto para chegar à falha. A fundação antecipou a divulgação em um dia.

O diretor de tecnologia da Cloudflare, Dane Knecht, disse que a empresa já observava as primeiras tentativas de exploração e liberou regras temporárias de bloqueio. A watchTowr relatou tentativas com ferramentas de prova de conceito feitas com IA — sem sucesso confirmado até então.

A descoberta tem um capítulo à parte. A OpenAI diz que os pesquisadores da Calif chegaram aos bugs usando suas ferramentas, num programa chamado “Patch the Planet”; OpenAI, Wiz e Trail of Bits também encontraram as mesmas falhas em auditorias. E uma delas, segundo a fundação, já tinha aparecido numa auditoria externa em 2024 — sem que nada fosse feito.

O que fazer hoje

• Atualizar para o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 — e reiniciar os serviços que executam PHP (PHP-FPM, Apache). Atualizar o pacote sem reiniciar deixa o processo antigo, vulnerável, no ar.
• Conferir a versão que o site usa, não só a do terminal. O comando php -v mostra a versão de linha de comando, que pode ser diferente da que o servidor web carrega.
• Distribuições Linux receberam as correções antecipadamente: o caminho é o pacote do fornecedor do sistema.
• PHP 8.1 ou anterior está fora de suporte. O projeto publicou remendos mínimos para 7.4, 8.0 e 8.1 voltados a quem compila do código-fonte; o resto precisa migrar. A linha 8.2 também chega ao fim em 31 de dezembro.
• Site em hospedagem ou loja virtual terceirizada? A pergunta vai para o provedor: o PHP do meu servidor já foi atualizado e reiniciado?

As medidas paliativas sugeridas pelo projeto — limitar o tamanho das requisições, desligar o progresso de upload de sessão — reduzem caminhos específicos, mas, nas palavras do próprio aviso, não tornam a instalação segura. O NCSC, centro de cibersegurança do Reino Unido, foi direto: atualizar imediatamente ou tirar o sistema do ar até atualizar.

Onde o estrago vai aparecer

WordPress, Drupal, Magento, Moodle e uma infinidade de sistemas internos que rodam no navegador são escritos em PHP. Em setembro, uma falha no WordPress precisava de um clique do administrador; esta não precisa do clique de ninguém. E na semana passada o nginx, que costuma ficar na frente desses sites, recebeu cinco correções — a camada da frente e a de baixo, no mesmo mês.

A Cisco Talos estima que cerca de metade dos sistemas vulneráveis pode nunca receber a correção. É nessa metade que vão aparecer os incidentes dos próximos meses: no servidor de um projeto antigo, no site de campanha esquecido, no sistema que “ninguém mais usa” e continua ligado.

Fontes

• PHP — “Security advisory: Critical remote code execution vulnerabilities, update now” e anúncios das versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 (21/10/2026): php.net
• BleepingComputer — “PHP ships emergency patches for critical PHP2Shell flaws” (21/10/2026): bleepingcomputer.com
• The Record — “Hundreds of websites taken offline as concern grows over two PHP vulnerabilities” (21/10/2026): therecord.media

• The Record — declaração da PHP Foundation sobre a descoberta e o vazamento antecipado das falhas (21/10/2026): therecord.media

• Foto de capa: elePHPant, o elefante de pelúcia mascote do PHP — Atomic Taco, CC BY-SA 2.0, via Wikimedia Commons

• Segunda imagem: código em PHP aberto em um editor — lmonk72, CC0, via Wikimedia Commons