PHP2Shell: as duas falhas críticas do PHP que ignoram sua tela de login

Na terça-feira, 20 de outubro, detalhes de duas vulnerabilidades no interpretador PHP vazaram antes do fim do embargo. Na quarta, 21, o projeto PHP publicou as correções em caráter emergencial. Entre um evento e outro, quem ataca teve uma janela que quem defende não teve.

As falhas receberam nota 9.2 na escala CVSS v4.0 e já ganharam apelido no mercado: PHP2Shell. O nome resume o problema - de PHP a um shell no seu servidor.

O que torna esse caso diferente

A maioria das vulnerabilidades web depende de uma falha na aplicação: um formulário mal validado, um plugin desatualizado, uma senha fraca. Aqui, não.

Pesquisadores que reproduziram o ataque confirmaram que o PHP processa a requisição maliciosa antes de executar qualquer linha do seu código. Na prática, autenticação, controle de acesso e regras de negócio da aplicação não chegam a entrar em jogo.

• CVE-2026-109618: corrupção de memória quando o PHP lida com um erro de falta de memória durante a requisição.

• CVE-2026-109619: estado de uma requisição anterior que sobrevive e é reaproveitado na seguinte.

Quem está exposto

Toda instalação PHP que atende requisições web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O próprio projeto PHP aponta o Apache com mod_php como o cenário de maior risco.

O PHP ainda roda boa parte da internet brasileira: sites institucionais, WordPress, e-commerces, portais de cliente, sistemas de gestão e painéis administrativos que muitas vezes nem aparecem no inventário de TI.

O problema do legado

As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.1 e anteriores estão fora de suporte e não terão pacote oficial corrigido - existem apenas backports em código-fonte para 7.4, 8.0 e 8.1, que exigem compilação manual.

Traduzindo: aquele sistema antigo que “funciona, então não mexe” virou o ponto mais frágil do ambiente. E o PHP 8.2 sai de suporte em 31 de dezembro de 2026, então o próximo legado já tem data marcada.

O que fazer agora

1. Inventário: descubra onde roda PHP, incluindo servidores esquecidos, ambientes de homologação expostos e sistemas de fornecedores.

2. Backup: faça snapshot antes de qualquer mudança.

3. Atualização: aplique o pacote corrigido da distribuição ou do painel. cPanel/WHM e Plesk já publicaram atualizações.

4. Reinício: reinicie PHP-FPM, Apache ou o servidor web. Sem isso, o código antigo continua em memória.

5. Verificação: confirme a versão em uso com php -v e com uma página phpinfo servida pelo próprio servidor web. Atualizar o pacote não é o mesmo que estar protegido.

6. Caça a indícios: arquivos desconhecidos em diretórios web, cron jobs novos, processos estranhos e picos de tráfego de saída.

Se a atualização não puder ser feita hoje, o advisory oficial do PHP lista medidas paliativas de configuração. Elas reduzem a exposição, mas não resolvem. Atualizar continua sendo a única correção completa.

A lição que fica

O PHP2Shell não vai ser a última falha crítica a vazar antes do patch. O que separa as empresas que atravessam esse tipo de evento com tranquilidade das que descobrem o problema semanas depois não é sorte - é saber exatamente o que está exposto, em que versão, e ter como provar que a correção foi aplicada.

Visibilidade contínua da superfície de ataque e validação ofensiva periódica transformam um alerta como este de crise em rotina.

Se quiser ajuda para mapear sua exposição ao PHP2Shell, fale com a Baikal.

Segurança não é um produto. É uma postura.

Referências: advisory oficial do projeto PHP; alertas do Centro Canadense de Cibersegurança (AL26-026), Rapid7, Sophos e Datadog Security Labs, todos de 21/10/2026.