PHP2Shell: a falha crítica no PHP que colocou 70% da internet em alerta

Duas vulnerabilidades críticas no interpretador PHP — registradas como CVE-2026-109618 e CVE-2026-109619, e batizadas de PHP2Shell — receberam nota CVSS v4.0 de 9.2 e colocaram em alerta a parcela da web que depende da linguagem, estimada em cerca de 70% dos sites. As correções saíram em 21 de outubro de 2026, e já há exploração observada em ambiente real.

O que aconteceu, em ordem

O projeto PHP publicou um lançamento de segurança corrigindo duas falhas no próprio motor da linguagem. Não em um framework, não em um plugin, não em uma aplicação: no interpretador que executa o código.

Essa distinção é a razão de o alcance ser tão grande. Uma falha no WordPress afeta quem usa WordPress. Uma falha no PHP afeta quem usa qualquer coisa escrita em PHP — e isso inclui WordPress, Magento, Shopware, WooCommerce, Laravel, sistemas internos antigos e aquele painel que ninguém mexe desde 2019.

Segundo o relato do caso, as duas vulnerabilidades foram descobertas com auxílio de inteligência artificial. Vale registrar o detalhe porque ele aponta para onde a pesquisa de segurança está caminhando: revisão assistida de código em bases enormes e maduras, à procura de padrões que escaparam de anos de leitura humana.

O que as falhas permitem

O resumo prático tem duas partes, e a segunda costuma receber menos atenção do que merece.

A primeira é execução remota de código. É o pior cenário possível: um atacante consegue rodar comandos no servidor. Daí o nome — do PHP para o shell.

A segunda é vazamento de memória dos processos do PHP, sem necessidade de autenticação. A Qualys registrou que pesquisadores demonstraram essa divulgação de memória dos workers, e o que vive nessa memória é justamente o material sensível em trânsito: senhas, tokens de autenticação, chaves de API. Quem só atualizou o PHP e parou aí resolveu a porta de entrada e deixou em pé o que já pode ter saído por ela.

Sobre qual CVE corresponde exatamente a qual mecanismo, as análises públicas divergem. A Huntress descreve a CVE-2026-109618 como uma falha no tratamento de erro de falta de memória; a Sansec classifica as duas como erros de uso após liberação e associa a CVE-2026-109618 ao desserializador do progresso de upload; a Ellio atribui esse caminho de upload apenas à CVE-2026-109619. Enquanto os avisos oficiais do projeto não fecharem a questão, o mapeamento item a item deve ser tratado como não resolvido. O que não está em disputa é a severidade, nem a lista de versões corrigidas.

Versões corrigidas

As correções estão em:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Os ramos 7.4, 8.0 e 8.1 não receberam lançamento oficial, porque estão fora de suporte. Se é onde você está, a atualização não vai chegar pelo caminho normal: depende do pacote da sua distribuição ou de um fornecedor de suporte estendido. E se nem isso existir para o seu caso, o problema deixou de ser este CVE e passou a ser a versão.

Quem é afetado mesmo com código limpo

Este é o ponto que vale repetir para quem tem loja no ar.

A Sansec observa que, por estarem no motor, as falhas alcançam lojas em Magento, Shopware e WooCommerce ainda que o código próprio dessas lojas esteja impecável. Não há revisão de aplicação que resolva: a correção é a versão do PHP do servidor.

Há um atenuante real, e é honesto registrá-lo. A maior parte das provas de conceito públicas exige que a aplicação alvo tenha, além do PHP vulnerável, uma falha de inclusão de arquivo local. Isso estreita o caminho, mas estreitar não é fechar — e a Aikido aponta que desativar um recurso legado pouco usado é uma forma confirmada de remover um dos caminhos para a CVE-2026-109619, o que vale manter desligado mesmo em sistema já corrigido.

O que fazer agora

Na ordem, porque a ordem importa.

1. Levante o inventário. Descubra qual versão do PHP roda em cada host. O servidor que não aparece na sua lista é exatamente o que vai ficar sem patch — o ambiente de homologação, o subdomínio antigo, a VPS de um projeto encerrado que continua respondendo.

2. Atualize para a versão corrigida do seu ramo. Hospedagem gerenciada normalmente faz isso por você, mas confirme em vez de supor: peça a versão exata em execução.

3. Rotacione credenciais. Trate como potencialmente expostas as senhas, tokens e chaves que passaram pelos processos do PHP antes da atualização. Isso é consequência direta do vazamento de memória, e é a etapa que mais gente pula.

4. Procure sinais de exploração anterior ao patch. Como há exploração em ambiente real, atualizar hoje não diz nada sobre o que aconteceu ontem. Vale revisar logs de acesso, arquivos modificados, tarefas agendadas e usuários criados no período.

A leitura que fica

PHP2Shell é um bom retrato de três coisas acontecendo ao mesmo tempo.

Infraestrutura antiga e onipresente continua carregando risco concentrado: quando a falha está na camada que todos pisam, a superfície de ataque é o tamanho da web. Pesquisa de segurança assistida por IA está encontrando o que anos de leitura humana não encontraram, o que significa mais achados críticos em código maduro nos próximos anos — para os dois lados. E a parte que depende de gestão, não de tecnologia, segue sendo a mais frágil: a falha foi corrigida em um dia, e o inventário de servidores da maior parte das empresas vai levar semanas para refletir isso.

Fontes técnicas para quem quer ir ao detalhe: Huntress, watchTowr, Datadog Security Labs, Sansec, Qualys e Help Net Security.

---

Se o assunto aqui é como se testa a robustez de um sistema antes de o atacante testar por você, escrevi sobre red teaming e jailbreaks aplicados a modelos de IA, que é a mesma disciplina em outro alvo. E se a sua empresa precisa de alguém para olhar a infraestrutura e o risco com critério antes do próximo susto, é o tipo de trabalho que conduzo em consultoria de inteligência artificial — o contato é o caminho direto.