PHP2Shell: a falha crítica no PHP que pega quase todo site, e o que fazer no seu

Na terça, 20 de outubro, o time do PHP fez algo que quase nunca faz: avisou com um dia de antecedência que ia publicar uma correção de segurança, marcada para as 14h (UTC) do dia seguinte (php.net). Aviso prévio é o jeito de dizer aos administradores "deixem a equipe de prontidão". No dia 21, saíram quatro versões novas de uma vez, e a recomendação oficial veio sem rodeio: todos os usuários de PHP devem atualizar imediatamente.

O PHP roda a maior parte dos sites do mundo, inclusive praticamente todo WordPress, loja virtual pequena e sistema feito sob medida em hospedagem compartilhada. Este blog roda em PHP, assim como os sites dos meus clientes. Então vamos por partes: o que aconteceu, o que a falha faz, quem está exposto e o que fazer em cada caso.

O que aconteceu, com fonte

• 20 de outubro: o PHP anuncia a correção para o dia seguinte e adianta que são duas falhas críticas, nota 9,2 de 10 na escala CVSS 4.0 (php.net).
• 21 de outubro: saem o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, que corrigem a CVE-2026-109618 e a CVE-2026-109619. As falhas foram encontradas por pesquisadores da Calif, da OpenAI e da Wiz, e ganharam o apelido de PHP2Shell (BleepingComputer).
• Ataques antes da correção: o CTO da Cloudflare, Dane Knecht, disse que a empresa já observava os primeiros ataques antes de as versões corrigidas saírem. O centro nacional de cibersegurança do Reino Unido (NCSC) recomendou atualizar imediatamente ou tirar os sistemas afetados do ar (BleepingComputer).
• Escala: pela estimativa do VirusTotal citada na mesma reportagem, mais de 5,1 milhões de servidores com PHP estão expostos na internet.
• 23 de outubro: o PHP publica um aviso complementar sobre uma terceira falha (CVE-2026-115560), num cenário que ele mesmo considera improvável, e recomenda desligar uma configuração até a próxima versão regular (php.net). Falo dela mais abaixo.

Uma ressalva honesta: nos primeiros dias as fontes divergiram sobre a extensão da exploração real e sobre quais versões antigas são afetadas. O que está acima é o que o próprio PHP e a reportagem de primeira linha afirmam. O resto eu deixei de fora.

O que a falha faz, sem jargão

Um servidor PHP não cria um processo novo para cada visitante. Ele mantém alguns "trabalhadores" (workers) ligados, e cada um atende uma requisição atrás da outra. Entre uma e outra, o PHP faz uma faxina na memória para o próximo visitante começar do zero.

As duas falhas atacam essa faxina:

• CVE-2026-109618: quando a memória acaba no meio de uma requisição, o PHP pode ser interrompido com dados internos pela metade, e a limpeza trata esse lixo como se fosse dado válido.
• CVE-2026-109619: um pedaço de estado de uma requisição pode sobreviver depois que a memória dele foi liberada. A próxima requisição atendida pelo mesmo trabalhador pode usar esse resto antes de a faxina acontecer.

Nos dois casos, um invasor que prepara a requisição certa consegue corromper a memória do trabalhador e, a partir daí, executar o código que quiser no servidor. O detalhe que mais importa para quem tem um site: no cenário de maior risco (Apache com mod_php), o PHP diz ter um ataque demonstrado em que uma requisição sem login dispara o problema antes de qualquer código do site rodar. Não importa se o seu sistema foi bem escrito, nem se o WordPress está em dia. A falha está no motor, não no carro.

Quem está exposto

Segundo o aviso oficial, toda instalação de PHP que atende requisições web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. Na prática, isso inclui:

• sites em WordPress, Joomla, Laravel ou qualquer outro sistema em PHP;
• lojas virtuais em PHP (WooCommerce, OpenCart, PrestaShop);
• sistemas internos feitos sob medida, aquele painel que um freelancer fez anos atrás e ninguém mais mexe.

O grupo em maior risco é o último. O PHP 8.1 e tudo o que veio antes não recebem mais versões oficiais. O projeto publicou só correções em código-fonte para o 7.4, o 8.0 e o 8.1, que alguém precisa compilar e instalar à mão. E o PHP 8.2 deixa de receber correções em 31 de dezembro de 2026. Se o seu sistema só roda em PHP 7, ele estava com o relógio correndo antes dessa falha, e agora correu mais rápido.

O que fazer, conforme a sua hospedagem

Hospedagem compartilhada ou gerenciada

Aqui quem instala e atualiza o PHP é o provedor, não você. A sua parte é conferir se ele já fez. Os sites que eu mantenho estão na Hostinger, e o painel mostrou o aviso de que a correção tinha sido aplicada. Segundo o comunicado da própria Hostinger, as versões corrigidas foram instaladas em toda a plataforma até 22 de outubro, às 6h44 (UTC), para todas as versões de PHP do 5.2 ao 8.5 nos planos Web, Cloud e cPanel, e clientes desses planos não precisam fazer nada. A empresa também diz não ter visto aumento de infecções desde a divulgação (Hostinger).

Se o seu provedor é outro, procure o comunicado dele sobre PHP2Shell ou abra um chamado com a pergunta direta: "o PHP do meu plano já está com a correção das CVE-2026-109618 e 109619?". Provedor que não sabe responder a isso em outubro de 2026 já é uma resposta.

VPS ou servidor próprio

Aqui é com você. A única correção completa é atualizar para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Se não der para atualizar hoje, o PHP lista medidas que reduzem a exposição sem resolver, entre elas:

• desligar session.upload_progress.enabled (valor 0) no php.ini, no pool do PHP-FPM ou na configuração do servidor, e reiniciar todos os trabalhadores. O PHP avisa: não confie em ini_set() nem no .user.ini do FPM para isso;
• no PHP 8.5, também fatal_error_backtraces=0.

Esconder erros com display_errors ou @ não ajuda em nada, porque a falha não depende de a mensagem aparecer na tela.

Como conferir em dois minutos

1. Versão: no painel da hospedagem (normalmente em "Configuração do PHP" ou "PHP Info"), veja a versão de cada site. Precisa ser igual ou maior que as corrigidas da mesma linha.
2. Data de compilação: em hospedagem gerenciada, o provedor pode corrigir mantendo o número da versão. Nesse caso, o que vale é a build date no PHP Info: 21 de outubro de 2026 ou depois.
3. Não deixe um phpinfo.php público para conferir. Se precisar criar um, apague logo em seguida: ele mostra a um invasor exatamente a versão e a configuração que ele procura.

Por que isso vai continuar acontecendo

Na mesma semana, uma investigação da empresa de segurança NorForge, divulgada pela imprensa, descreveu um invasor que apontou agentes de IA para cerca de 1.200 sites de empresas e deixou que eles procurassem as brechas sozinhos. Segundo as reportagens, pelo menos 100 empresas foram comprometidas, com um gasto em torno de US$ 5 mil, ou uns US$ 50 por invasão (The Hacker News, Hardware.com.br). Os números ainda não foram publicados na íntegra pela empresa, então trate-os como ordem de grandeza.

Juntando as duas notícias: atacar está ficando barato, e falhas como o PHP2Shell dão uma porta de entrada pronta. O site que fica para trás numa atualização deixa de ser "alvo improvável" e vira item de uma lista que alguém varre automaticamente. Eu já tinha escrito sobre o mesmo padrão na falha do LiteSpeed em hospedagem compartilhada: o problema raramente é a falha em si, e quase sempre é ninguém saber o que está rodando.

Três hábitos resolvem a maior parte disso, e nenhum exige equipe de segurança:

• Saber a versão do PHP de cada site, e anotar quando cada linha deixa de ter suporte;
• Escolher hospedagem que corrige sozinha e avisa, em vez de depender de alguém lembrar;
• Ter um plano para o sistema antigo que só roda em PHP 7, antes da próxima falha, e não depois. Organizar isso sem planilha é o assunto de gestão de vulnerabilidades.

Quero uma revisão do meu site em PHP

Datas, versões e números conferidos nas fontes linkadas em 25 de outubro de 2026. O que só o provedor afirma está atribuído a ele.