PHP2Shell: como o Myrmex ajuda a investigar, corrigir e comprovar a resposta

Depois de descobrir os hosts afetados pelo PHP2Shell, vem a parte mais complexa da resposta: investigar cada servidor, identificar quais são críticos e precisam ser corrigidos em horários específicos, preparar essas mudanças, executá-las na janela, coletar as evidências e escrever o relatório.

O Myrmex ajuda seus clientes na investigação, no planejamento, na ação e nas evidências, com aprovação humana em cada etapa. Este artigo resume o que se sabe sobre o PHP2Shell e mostra como conduzir a resposta, do inventário ao relatório.

Em 21 de outubro de 2026, o projeto PHP publicou correções de emergência para CVE-2026-109618 e CVE-2026-109619, conhecidas como PHP2Shell. São duas falhas críticas no núcleo do PHP, ambas com CVSS 9.2, que permitem a um atacante remoto executar comandos no servidor web. Como a exploração acontece antes de qualquer código da aplicação rodar, ela deixa pouco ou nenhum rastro nos logs da aplicação.

O que é o PHP2Shell

As duas falhas compartilham a mesma causa raiz. Quando o PHP encontra uma condição fatal no meio do processamento de uma requisição, como estourar o memory_limit, atingir o tempo máximo de execução ou perder a conexão do cliente, ele aborta a requisição sem desfazer as estruturas que estava montando. Depois, a rotina de encerramento trata esses dados pela metade como se fossem válidos.

• CVE-2026-109618 (falta de memória, na mesma requisição). Um corpo de requisição POST preparado para isso estoura a memória durante a leitura das variáveis da requisição e deixa uma estrutura parcialmente inicializada, que o próprio encerramento da requisição usa. Uma única requisição basta.
• CVE-2026-109619 (estado global inválido, entre requisições). Um erro fatal deixa ponteiros globais apontando para memória já liberada, e a próxima requisição atendida pelo mesmo processo os usa. São duas etapas: envenenar e disparar. Processos persistentes, como o Apache com mod_php, amplificam o problema.

Pesquisadores também demonstraram a leitura de memória dos processos PHP, o que pode expor senhas, tokens e chaves de API.

As falhas foram encontradas com ajuda de inteligência artificial, de forma independente, pelas empresas de segurança Calif, num programa conduzido com a OpenAI, e Wiz. Sinais do mesmo problema de memória já tinham aparecido numa auditoria da Quarkslab em 2024. O PHP é a linguagem por trás de cerca de 70% dos sites da web, e uma parte grande deles roda versões antigas, já sem correção oficial.

Uma correção antecipada e uma corrida contra o relógio

A divulgação estava combinada para depois da correção, mas os detalhes vazaram antes:

• 17/out: os servidores-isca da Amazon registraram uma tentativa de exploração, quatro dias antes da divulgação pública.
• 20/out: os identificadores das falhas começaram a circular em fóruns, e o PHP antecipou a publicação da correção. No mesmo dia, um vídeo com a exploração funcionando vazou e se espalhou pelas redes sociais.
• 21/out, madrugada: a Cloudflare ativou regras de proteção para todos os clientes.
• 21/out, 8h35 (Brasília): a Hadrian registrou exploração em escala, horas antes de a correção oficial ficar disponível.
• 21/out: o PHP publicou as versões corrigidas.

O impacto no Brasil

No Brasil, a resposta veio no mesmo dia. Em 21 de outubro, o Centro Integrado de Segurança Cibernética do Governo Digital (CISC gov.br) emitiu um alerta, repassado pelo CTIR Gov às equipes de tecnologia do governo federal, e o GSI orientou os gestores a atualizar os sistemas imediatamente. As recomendações seguem o mesmo roteiro deste artigo: atualizar o PHP, mapear os servidores que usam a linguagem, priorizar os expostos à internet e isolar temporariamente o que não puder ser atualizado.

O SEI, o sistema eletrônico de processos usado em todo o governo federal e em estados e municípios, roda em PHP. Por precaução, a Anatel suspendeu o acesso externo ao SEI, e os Tribunais Regionais Federais da 1ª, 4ª e 6ª Regiões adotaram medidas semelhantes.

Quem está afetado

• Versões: todo o PHP de 5.4 a 8.5.11.
• Versões corrigidas: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. As versões 8.1 e anteriores estão fora de suporte; há correções mínimas em código-fonte para 7.4, 8.0 e 8.1, e as distribuições Linux publicam pacotes próprios, que podem manter o número de versão antigo.
• Formas de execução: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed, ou seja, qualquer PHP que atenda requisições web. O mod_php é o cenário mais arriscado.
• Não depende da aplicação: a falha está no processamento da requisição pelo próprio PHP, então independe de framework ou CMS.
• Configuração conta: o caminho de falta de memória fica alcançável quando o corpo da requisição pode crescer o bastante para estourar o memory_limit antes de o script rodar, o que acontece quando o memory_limit é menor que cerca de 4 vezes o post_max_size. Os valores padrão do PHP não atendem a essa condição, mas servidores configurados para uploads grandes atendem, e o post_max_size pode ser alterado por diretório ou por site.

Com exploração já registrada, trate como urgente.

Estou afetado? O que verificar

1. Inventário. Liste todos os servidores com PHP, inclusive instalações fora do gerenciador de pacotes. Lembre que o php -v da linha de comando pode ser outra instalação, diferente da que atende o site.
2. Versão e pacote. Compare a versão (ou o pacote da distribuição) com as versões corrigidas.
3. Forma de execução. Identifique se é mod_php, PHP-FPM, php-cgi, FrankenPHP ou LiteSpeed.
4. Configuração. Revise memory_limit, post_max_size e upload_max_filesize, incluindo sobrescritas por diretório (.htaccess, .user.ini, virtual hosts).
5. Exposição. Priorize o que está acessível pela internet.
6. Sinais de exploração. Procure no log de erros do servidor web a combinação "Allowed memory size of N bytes exhausted" com "in Unknown on line 0", que indica uma falha antes de qualquer arquivo PHP rodar. E procure processos do servidor web ou do PHP abrindo shells ou outros processos inesperados.

Como o Myrmex ajuda a responder

Tudo começa com um pedido em linguagem natural, como "Encontre todos os hosts afetados pelo PHP2Shell, corrija o PHP e me dê a evidência para o relatório." A partir daí, o Myrmex conduz as quatro etapas que mais consomem tempo da equipe:

• Investigar. O Perseus usa o agente Myrmex instalado nos servidores para levantar, de cada host, a versão do PHP, o pacote, a forma de execução e os valores de memory_limit e post_max_size, incluindo as sobrescritas por site. Ele também procura no log de erros do servidor web o padrão "in Unknown on line 0" e cruza com os alertas do seu EDR ou SIEM, em busca de processos do servidor web abrindo shells.
• Planejar. Com a topologia e o inventário, o Myrmex separa o que é crítico, exposto à internet ou de produção, do que pode seguir uma mudança padrão. Para os críticos, ele monta as GMUDs já preenchidas: hosts afetados, impacto, janela, plano de implementação e rollback.
• Agir. Cada GMUD segue as regras de aprovação da sua equipe e só roda depois de aprovada, na janela definida. Se a correção precisar esperar, os paliativos de configuração também passam por aprovação, com o aviso de que eles não cobrem todos os caminhos de ataque.
• Evidenciar. Antes e depois de cada atualização, o Myrmex registra a versão e o pacote e verifica de novo. O Scribe monta o relatório do incidente: hosts encontrados, o que foi corrigido, quando, por quem foi aprovado e o que ainda está pendente, pronto para a auditoria, o comitê ou o cliente. Para acompanhar a frota, a verificação pode virar um runbook agendado em Books.

Cada passo fica na lista de passos da conversa e nos logs de auditoria, e nada muda em produção sem a sua aprovação. (Por que isso importa: Aprovação humana que não é teatro.)

A IA está dos dois lados

O PHP2Shell mostra os dois lados da IA em segurança. Ela ajudou a encontrar uma falha que estava escondida no núcleo do PHP havia anos, e o vazamento mostrou como uma exploração funcional se espalha antes da correção. A resposta precisa ter a mesma velocidade. É para isso que o Myrmex existe: agentes de IA que investigam, planejam, executam e documentam a correção com a sua equipe no comando.

Recomendações

• Atualize o PHP. É a única correção completa. Use as versões 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou o pacote corrigido da sua distribuição.
• Não confie só em paliativos. Desativar o session.upload_progress cobre apenas os caminhos de sessão de uma das falhas. Limites de memória por cgroup, reduzir post_max_size e upload_max_filesize e, no PHP 8.5, fatal_error_backtraces=0 ajudam enquanto a correção não sai, mas não substituem a atualização.
• Reinicie os processos. Depois de atualizar ou mudar configurações, reinicie todos os processos do PHP e do servidor web.
• Isole o que não puder corrigir agora. Restrinja o acesso público ou tire o serviço do ar até atualizar.
• Procure sinais de exploração nos servidores que ficaram expostos antes da correção.

Fale com a nossa equipe para revisar a exposição do seu ambiente ao PHP2Shell.