PHP2Shell: tentativas de ataque começaram quatro dias antes da divulgação
Uma tentativa de explorar as vulnerabilidades conhecidas como PHP2Shell foi identificada quatro dias antes de os problemas serem divulgados publicamente. A equipe de inteligência de ameaças da Amazon registrou a atividade em 17 de outubro de 2026, por meio do MadPot, serviço da empresa que utiliza honeypots para detectar ataques. Depois da publicação das correções, novas tentativas também foram observadas.
Segundo CJ Moses, diretor de segurança da informação da Amazon Integrated Security, a ação inicial teve origem no endereço IP 103.216.220[.]92, localizado na Austrália e associado a uma rede comercial de anonimização. O uso desse tipo de infraestrutura para atacar um honeypot indica atividade maliciosa. Ainda não se sabe, porém, como os responsáveis conseguiram informações sobre as falhas antes do anúncio oficial.
As vulnerabilidades receberam os identificadores CVE-2026-109618 e CVE-2026-109619 e uma nota 9,2 na escala CVSS v4.0, que mede a gravidade de falhas de segurança. Descobertas por pesquisadores da Calif, da OpenAI e da Wiz, companhia pertencente ao Google, elas afetam componentes centrais do PHP e podem permitir execução remota de código sem autenticação.
O problema abrange versões das séries PHP 7.x e 8.x. Na prática, um invasor pode tentar explorá-lo por meio de endpoints acessíveis pela internet, como formulários, páginas de login e rotinas de verificação de integridade. Como as falhas estão no próprio interpretador, a vulnerabilidade não depende de um CMS, framework ou conjunto específico de plugins. Mais de 2,6 milhões de servidores PHP estão expostos à internet, ampliando a dimensão potencial do risco.
A detecção pode ser difícil. De acordo com a CrowdStrike, a exploração pode acontecer sem provocar mudanças visíveis no comportamento dos serviços: os processos do servidor continuam ativos, as requisições podem receber respostas HTTP com código 200 e os registros da aplicação talvez não mostrem anormalidades. Isso ocorre porque o ataque pode atingir o PHP antes que o código da aplicação seja executado.
Em algumas situações, o indício mais claro pode ser uma falha fatal associada ao limite de memória, gravada no log de erros do servidor web. Como esse tipo de registro também pode aparecer em circunstâncias rotineiras, equipes de segurança precisam avaliar o contexto e procurar sinais adicionais, em vez de tratar cada ocorrência isoladamente.
A divulgação coordenada estava programada para 22 de outubro de 2026, às 14h UTC. No entanto, o vazamento antecipado dos identificadores CVE e de um código de prova de conceito, ou PoC, levou a PHP Foundation a adiantar a publicação das correções para 21 de outubro. Segundo a fundação, os problemas envolvem mecanismos fundamentais de gerenciamento de memória e tratamento de erros. Corrigi-los exigiu atenção especial para manter a compatibilidade, o desempenho e o funcionamento de extensões de terceiros.
As tentativas não cessaram após a divulgação. Em 21 de outubro, por volta das 2h UTC, a Amazon detectou novas requisições contra seus honeypots. A atividade prosseguiu durante as seis horas seguintes, com diferentes payloads e serviços de anonimização. Entre os endereços IP associados estavam 31.223.184[.]166, 37.19.200[.]5, 134.209.159[.]64, 103.114.163[.]188 e 95.217.98[.]37. A variedade de técnicas e infraestruturas pode indicar a atuação de mais de um invasor, embora a empresa não tenha confirmado se houve ataques bem-sucedidos contra sistemas reais.
A companhia de segurança ELLIO também observou atividade relacionada ao PHP2Shell. Seus sensores registraram a primeira requisição maliciosa em 21 de outubro, às 8h36 UTC, menos de uma hora após a Chainguard publicar imagens de software com as correções. A PHP Foundation acusou a empresa de ter quebrado o embargo de divulgação. A Chainguard recebera os patches antes do anúncio para preparar atualizações para seus clientes; a publicação antecipada das imagens, segundo a fundação, poderia permitir que invasores examinassem as correções em formato binário e deduzissem como explorar as falhas.
Diante da gravidade do caso, o National Cyber Security Centre (NCSC), do Reino Unido, e a Cybersecurity and Infrastructure Security Agency (CISA), dos Estados Unidos, recomendaram aplicar as atualizações imediatamente ou, quando isso não fosse possível, retirar temporariamente da internet os sistemas vulneráveis.
O FBI orientou administradores a acompanhar comportamentos incomuns em servidores web, especialmente processos PHP que iniciem shells de comando sem motivo esperado ou tentem baixar arquivos. O uso de ferramentas de monitoramento de processos pode ajudar a identificar essas ações. Já a National Security Agency (NSA) alertou que a exploração pode abrir caminho para arquivos e bancos de dados armazenados nos servidores afetados. A OpenAI classificou o PHP2Shell entre os problemas de segurança de maior impacto dos últimos tempos.
Para reduzir o risco, equipes responsáveis devem primeiro inventariar os servidores e identificar quais versões do PHP estão em uso, incluindo instalações em máquinas virtuais, contêineres e serviços administrados por terceiros. Depois, é necessário aplicar a versão corrigida correspondente e confirmar que a atualização foi concluída em todos os ambientes, não apenas nos servidores mais visíveis.
Quando a correção imediata não for viável, limitar temporariamente o acesso público aos sistemas vulneráveis pode diminuir a exposição. Restrições por endereço IP, regras de firewall e a desativação de endpoints que não sejam essenciais são medidas de contenção, não substitutos para a atualização. A decisão deve considerar quais serviços precisam permanecer disponíveis e quais podem ser isolados até a correção.
Também é recomendável preservar e revisar logs do servidor web, do sistema operacional e de ferramentas de segurança. A busca deve incluir processos filhos inesperados do PHP, comandos de shell, downloads não autorizados, acessos incomuns a arquivos e alterações em contas ou tarefas agendadas. Como os registros podem não revelar toda a atividade, a análise precisa combinar diferentes fontes de telemetria.
Por fim, organizações que encontrem sinais de exploração devem tratar o incidente como possível comprometimento, e não apenas instalar o patch e encerrar a investigação. A redefinição de credenciais expostas, a verificação de bancos de dados e arquivos, a análise de persistência e a reconstrução de sistemas quando necessário ajudam a impedir que um invasor mantenha acesso mesmo após a atualização.