Duas falhas críticas no núcleo do PHP permitem execução remota de código sem autenticação. Entenda como o ataque funciona e o que fazer agora.
Na última semana de outubro de 2026, o projeto PHP divulgou correções emergenciais para dois problemas sérios no núcleo da linguagem: o CVE-2026-109618 e o CVE-2026-109619, ambos com nota 9.2 no CVSS v4.0. Pesquisadores já batizaram o conjunto de técnicas de exploração como PHP2Shell — e o nome não é por acaso.
O que torna esse ataque diferente
A maioria das vulnerabilidades web que vemos no dia a dia mora no código da aplicação: um plugin mal feito no WordPress, uma rota sem validação numa API, um upload sem checagem de tipo. Você corrige o plugin, fecha o buraco, vida segue.
O PHP2Shell não é assim.
Ele fica dentro do próprio motor do PHP — na camada de gerenciamento de memória e tratamento de erros do interpretador. Isso tem uma consequência bem específica: a falha é explorada antes que qualquer linha do seu código de aplicação seja executada. Não importa se o seu sistema é seguro. Se o PHP que roda embaixo dele está desatualizado, você está exposto.
Como o ataque acontece, passo a passo
Sem entrar em detalhes que seriam úteis só pra quem quer explorar a falha, o fluxo geral funciona assim:
O atacante envia uma requisição HTTP especialmente montada — geralmente um POST com formato multipart/form-data (o mesmo usado em uploads de arquivos comuns). Sem autenticação. Sem precisar de usuário ou senha.
O PHP tenta processar a requisição, fica sem memória no meio do caminho e trava o processo de uma forma específica. Durante a limpeza desse erro, estruturas internas ficam em estado inconsistente — dados de requisições anteriores "vazam" para a próxima requisição processada pelo mesmo worker.
Com o controle desse estado corrompido, o atacante consegue executar código diretamente no processo do servidor web. Nenhum log de aplicação registra nada fora do normal. O servidor responde com um HTTP 200 OK.
Depois de entrar, a prioridade é persistência. O atacante planta uma webshell — um script PHP simples escondido em alguma pasta da aplicação — e a partir daí não precisa mais explorar a vulnerabilidade. Ele acessa o servidor via requisições HTTP normais, com controle total.
O resto é escalada: leitura de arquivos de configuração, dump de banco, movimentação lateral pela rede interna, exfiltração de dados.
Tem um detalhe que vale destacar: o CVE-2026-109619 também permite leitura da memória do processo do servidor web sem executar código. Isso significa que um atacante pode, silenciosamente, ler tokens de API, senhas e sessões de outras requisições que estão sendo processadas ao mesmo tempo. Sem deixar rastro.
O papel do EDR nesse cenário
Soluções de EDR como o SentinelOne Singularity ganham visibilidade onde o worker PHP roda no host. Na prática, isso significa que comportamentos pós-exploração são detectáveis:
O processo do servidor web (apache2, php-fpm, php-cgi) abrindo um shell do sistema operacional
Arquivos PHP novos aparecendo em diretórios da aplicação com funções suspeitas como eval(), system(), shell_exec()
Conexões de saída inesperadas para infraestrutura de C2
Aqui no nosso SOC, esse tipo de comportamento é exatamente o que os alertas de detecção comportamental do SentinelOne são treinados para pegar — mesmo quando o vetor de entrada inicial não deixa log explícito.
O ponto importante é entender que EDR e patch não são concorrentes — são complementares. O EDR cobre o pós-exploração. O patch cobre a entrada. Você precisa dos dois.
O que fazer agora
Sem enrolação:
1. Atualize o PHP imediatamente. As versões corrigidas são:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Se você usa PHP via pacotes do sistema operacional (Ubuntu, Debian, RHEL), verifique se o repositório já tem os backports de segurança e atualize pelos pacotes do OS — não necessariamente pela versão upstream.
2. Rotacione credenciais. Se o seu ambiente ficou exposto antes da atualização, considere o pior: credenciais de banco, tokens de API, senhas de serviços podem ter sido lidas da memória do processo. Troque tudo que estiver no ambiente de produção.
3. Audite arquivos na raiz web. Procure por arquivos .php criados ou modificados recentemente em pastas de upload, assets ou qualquer diretório acessível via HTTP. Webshells costumam se esconder em nomes genéricos como image.php, thumb.php, config.php.
4. Revise logs de acesso. Mesmo que os logs da aplicação não mostrem nada, os logs do servidor web (Apache, NGINX) vão ter registros das requisições. Procure por POST requests com corpos muito grandes para endpoints que normalmente não recebem uploads.
5. Se você usa WAF, verifique se as regras para payloads multipart malformados estão ativas. Não é uma correção definitiva, mas reduz a superfície enquanto o patch não é aplicado.
Um contexto que merece atenção
Um detalhe que circulou nas discussões técnicas sobre o PHP2Shell: a cadeia de exploração final foi desenvolvida com auxílio de modelos de IA. Uma fraqueza que anteriormente era classificada como "provavelmente não explorável" se tornou um RCE confiável quando pesquisadores usaram IA para analisar e montar o exploit.
Isso não é alarmismo — é um sinal real de como o cenário de ameaças está evoluindo. A barreira pra transformar uma vulnerabilidade complexa em arma está caindo. O tempo entre divulgação e exploração em larga escala também.
Como a Plattano pode ajudar
Se você é cliente Plattano com cobertura de SOC, nosso time já está monitorando IoCs relacionados ao PHP2Shell nos ambientes gerenciados. Se quiser uma revisão da postura de segurança dos seus servidores web ou tem dúvidas sobre atualização de PHP em ambientes críticos, fale com a gente.
Se você ainda não tem visibilidade comportamental nos seus endpoints e servidores, esse é um bom momento pra conversa. O SentinelOne Singularity detecta exatamente o tipo de comportamento pós-exploração que ataques como esse deixam como rastro.
Fontes: SentinelOne Threat Research, PHP Project Security Advisories, análises da comunidade de segurança.