Detecção antes do alarme: o que o caso PHP2Shell revela sobre o cenário atual de ameaças
A equipe de Inteligência de Ameaças da Amazon registrou algo preocupante: uma tentativa de exploração da vulnerabilidade conhecida como PHP2Shell já havia sido detectada em 17 de outubro de 2026 — quatro dias antes de as CVEs relacionadas (CVE-2026-109618 e CVE-2026-109619) serem divulgadas publicamente. A detecção ocorreu por meio da rede MadPot, sistema interno de honeypots (armadilhas digitais usadas para atrair e monitorar agentes maliciosos) da AWS.
A tentativa partiu de um endereço IP associado a uma rede comercial de anonimização. O fato de um honeypot ter sido alvo durante o período de embargo — quando a vulnerabilidade ainda estava sob sigilo — sugere fortemente que o ator por trás da ação obteve informações sobre o exploit antes da divulgação oficial. Como isso aconteceu ainda é incerto.
A linha do tempo da exploração
O embargo estava programado para ser encerrado em 21 de outubro de 2026, às 14h UTC. Mas antes mesmo disso, a Inteligência de Ameaças da Amazon já identificava provas de conceito (PoCs) circulando: a mais antiga registrada foi às 2h UTC do mesmo dia — ou seja, 12 horas antes da janela oficial de divulgação.
Entre 2h e 8h UTC de 21 de outubro, múltiplas tentativas de exploração do PHP2Shell foram detectadas contra os sensores MadPot, originadas de diferentes infraestruturas anonimizadas. A variação nos payloads e nas escolhas de infraestrutura indica que não se tratava de um único ator, mas de múltiplos grupos agindo de forma independente.
Após o levantamento oficial do embargo e a publicação do patch, novos exploits de prova de conceito surgiram em questão de horas, e foram usados contra os sensores quase imediatamente. Hoje, o PHP2Shell está sendo explorado ativamente em larga escala.
Vale destacar que a análise técnica ainda está em andamento, e não há confirmação se alguma dessas tentativas teria obtido sucesso em sistemas reais.
Duas lições que vão além do PHP2Shell
1. O embargo protege os defensores — mas não de todos
A divulgação coordenada de vulnerabilidades (Coordinated Disclosure) continua sendo o modelo correto. Ela garante que fornecedores tenham tempo para desenvolver e distribuir correções antes que o problema se torne público. No entanto, o caso PHP2Shell demonstra que o período de embargo não pode ser tratado como uma garantia de segurança absoluta.
Se um agente malicioso descobre a mesma vulnerabilidade de forma independente — ou obtém informações vazadas durante o período de sigilo —, a exploração pode começar antes da data oficial de divulgação. Isso significa que, ao investigar um possível comprometimento relacionado ao PHP2Shell, o ponto de partida deve ser pelo menos 17 de outubro, não 21 de outubro.
2. O tempo entre patch e exploit funcional está encolhendo
Historicamente, a maioria das explorações observadas ocorria após a publicação de uma prova de conceito pública. Um grupo pequeno de atores mais capacitados desenvolvia o exploit, e os demais aguardavam. Esse padrão está mudando.
A análise assistida por Inteligência Artificial (IA) tornou mais barato e rápido transformar o diff de um patch ou um advisory técnico em um exploit funcional. Com isso, um número maior de atores consegue agir em horas — ou até minutos — após a divulgação de detalhes técnicos de uma vulnerabilidade.
Para líderes de segurança, isso altera algumas premissas fundamentais:
- Para vulnerabilidades críticas em sistemas expostos à internet, meça os prazos de aplicação de patches e mitigações em horas. Um SLA de 7 ou 30 dias pressupõe uma janela de atraso que simplesmente não existe mais.
- Inicie investigações a partir da data mais antiga de exploração conhecida, não da data de divulgação. No caso do PHP2Shell, isso significa investigar a partir de 17 de outubro.
- Invista em detecções que não dependam de assinatura específica para uma CVE. A primeira exploração frequentemente chega antes de essas assinaturas existirem.
Como a AWS ajuda a proteger os clientes
A AWS opera múltiplas camadas de proteção para seus clientes. O sistema interno de inteligência de ameaças da empresa detectou e restringiu automaticamente tentativas maliciosas de varredura relacionadas a essa vulnerabilidade. A infraestrutura analisa mais de 200 bilhões de eventos por minuto e integra inteligência de ameaças da rede de honeypots MadPot para identificar e bloquear tentativas de exploração conhecidas em tempo real.
Ações recomendadas imediatamente
Para quem opera ambientes PHP, as recomendações são diretas:
- Atualize imediatamente para as versões corrigidas do PHP. A atualização é a única remediação completa para as duas CVEs. Não existem workarounds apenas de configuração que resolvam ambos os problemas de forma integral.
- Considere bloquear uploads de arquivos multipart em implantações PHP que não possam ser corrigidas imediatamente — mas avalie o impacto na aplicação antes de aplicar essa medida.
- Monitore requisições POST que contenham a string
PHP_SESSION_UPLOAD_PROGRESSem uploads de formulários. - Revise os logs do servidor web em busca de atividades suspeitas.
- Verifique execuções de processos inesperadas ou modificações de arquivos em servidores de aplicações web.
Indicadores de Comprometimento (IOCs)
A Inteligência de Ameaças da Amazon identificou os seguintes endereços IP associados à exploração do PHP2Shell:
103.216.220.92— observado em 17/10/202631.223.184.166— observado em 21/10/202637.19.200.5— observado em 21/10/2026134.209.159.64— observado em 21/10/2026103.114.163.188— observado em 21/10/202695.217.98.37— observado em 21/10/2026
Importante: os endereços identificados fazem parte de infraestruturas de anonimização compartilhadas e não são exclusivos dessa atividade maliciosa. A recomendação é investigar qualquer observação envolvendo esses IPs — e não simplesmente bloqueá-los de forma indiscriminada.
Mitigação com AWS WAF enquanto o patch não é aplicado
Para quem ainda não conseguiu aplicar o patch, a AWS publicou orientações específicas sobre como usar o Firewall de Aplicação Web (AWS WAF) para reduzir a exposição durante o período de transição. Confira o post: Como usar o AWS WAF para aplicar mitigações para as vulnerabilidades RCE do PHP2Shell (CVE-2026-109618 e CVE-2026-109619).
Dúvidas? A AWS recomenda abrir uma thread no AWS re:Post ou entrar em contato com o Suporte AWS.
Fonte
Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot (https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/)
Leave a Reply