Em 21 de outubro de 2026, o projeto PHP divulgou atualizações emergenciais para corrigir duas falhas críticas catalogadas como CVE-2026-109618 e CVE-2026-109619. O alerta havia sido emitido por Plustag IA antes mesmo da liberação dos patches, e o acompanhamento continuou depois que a equipe analisou os detalhes técnicos das vulnerabilidades e testou tanto as versões corrigidas quanto as ainda vulneráveis do PHP. Até o momento, não foram observados comprometimentos confirmados decorrentes dessas falhas — um indicativo claro da complexidade da exploração, especialmente considerando que o firewall utilizado por Plustag IA protege mais de 5 milhões de sites WordPress.
Ataques ao PHP2Shell já somam dezenas de milhares de tentativas
Por meio das proteções embarcadas no firewall, Plustag IA já interceptou mais de 74 mil tentativas de exploração ou sondagem associadas às vulnerabilidades recém-divulgadas, além de ataques correlatos que abusam da mesma superfície envolvendo multipart e session-upload-progress do PHP. Diante desse cenário em constante evolução, Plustag IA está ampliando sua capacidade de monitoramento para acompanhar com mais precisão o comportamento dessa ameaça.
A recomendação de correção permanece a mesma: instalar o PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou um pacote de fornecedor que confirme explicitamente conter as duas correções, reiniciando em seguida todos os workers do PHP. Vale reforçar que atualizar o WordPress em si não atualiza o PHP — são processos distintos e igualmente necessários.
O que mostram os dados dos ataques
Um dos maiores clusters de ataque identificados com clareza utiliza requisições com corpo multipart contendo campos repetidos, organizados em uma estrutura aparente de execução de comandos, incluindo tentativas de leitura dos arquivos .env e wp-config.php. A requisição analisada traz campos “t[n]” repetidos diversas vezes — 134 deles foram omitidos do exemplo por questões de espaço — todos carregando a mesma string de comando, que tenta exibir variáveis de ambiente e trechos de arquivos de configuração comuns em instalações WordPress.
Esses campos repetidos são compatíveis com uma tentativa de gerar pressão de memória e moldar as alocações da requisição, enquanto a presença de uma string do tipo “system” e do marcador “P2S_OK” indica uma etapa de execução de comando embutida no ataque. Ainda assim, a existência dessa requisição, por si só, não comprova que houve corrupção de memória ou execução efetiva de comando — ela apenas revela, com bastante clareza, o que os atacantes estão tentando fazer.
Famílias de exploração identificadas no ataque ao PHP2Shell
Uma amostra de 10 mil eventos coletados entre 20 e 22 de outubro foi selecionada com base em requisições que referenciam o parâmetro PHP_SESSION_UPLOAD_PROGRESS. Por isso, essa amostra não deve ser tratada como representativa de todo o tráfego potencialmente malicioso observado. Mesmo assim, ela revela diversas famílias distintas de payload, e não apenas uma única prova de conceito:
- Tentativas de RCE por aparente OOM/corrupção de estado (padrão P2S): 3.752 eventos, com o objetivo de moldar alocações da requisição, tentar execução de comandos e roubar dados de configuração.
- Tentativas de cadeia de gadgets via objetos serializados do Laravel: 1.139 eventos, buscando invocar um gadget disponível na aplicação para executar comandos de shell.
- Outros payloads de objetos serializados: 2.534 eventos, testando classes instaladas de Monolog, Symfony, Guzzle, WordPress, ThinkPHP e outras.
- Tentativas relacionadas de envenenamento de arquivo de sessão (NxSP): 512 eventos, buscando envenenar um arquivo temporário de sessão combinado a uma falha separada de inclusão local de arquivo.
- Testes de canário de upload PHP fora de banda: 30 eventos, verificando se outro mecanismo de upload ou execução provoca um callback.
Os números referentes a objetos serializados descrevem características do payload e podem se sobrepor a outras categorias comportamentais. Importante destacar que a amostra contém apenas requisições, sem corpos de resposta ou telemetria de endpoint — ou seja, esses números medem tentativas de exploração, não comprometimentos efetivamente bem-sucedidos.
A atribuição correta é essencial nesse contexto. O tráfego relacionado ao P2S e a objetos serializados é compatível com tentativas de explorar o comportamento corrigido pelas recentes atualizações do PHP. Já as requisições de envenenamento de sessão via NxSP e os pequenos canários de upload PHP usam a mesma superfície de multipart ou upload-progress, mas dependem de falhas separadas ou de comportamentos específicos de cada aplicação — por isso não devem ser descritos como exploração confirmada das CVE-2026-109618 ou CVE-2026-109619.
Objetivos identificados por trás das tentativas
A análise do comportamento dos atacantes permitiu mapear uma sequência de intenções bastante definida:
- Confirmar a execução de comandos usando marcadores como P2S_OK, NxSP<número> e SHL_OK.
- Mapear o servidor por meio de comandos como id, uname -a e hostname.
- Roubar credenciais e segredos a partir de variáveis de ambiente, do arquivo .env e do wp-config.php.
- Instalar acesso persistente, vasculhando diretórios comuns de CMS e tentando gravar um shell de comando em PHP chamado wp2s.php em locais graváveis de upload, plugins ou temas.
- Buscar e executar um payload de segundo estágio usando curl, wget e um interpretador de shell.
- Verificar a execução fora de banda por meio de nomes de host de callback únicos, em serviços como oast.pro, oast.fun e oast.online.
Para equipes de defesa, alguns indicadores não relacionados a IP merecem atenção redobrada: P2S_OK, o padrão NxSP[0-9]+, SHL_OK, ADV618BOUNDARY, —-P2SB, wp2s.php, php2shell.php, arquivos do tipo axiom_*.php, a expressão php-to-shell, além de classes como IlluminateBroadcastingPendingBroadcast, MonologHandlerBufferHandler e Requests_Utility_FilteredIterator.
Os IPs mais ativos no ataque
Entre os 20 endereços de origem mais ativos, que respondem pela maior parcela das tentativas bloqueadas, destacam-se o IP 87.121.84.174, com 8.525 tentativas registradas, seguido por 181.215.186.252 (7.856), 185.196.220.132 (7.146), 185.161.210.29 (5.796) e 152.233.51.69 (5.317). Outros endereços relevantes incluem 45.134.225.16 (3.623), 107.189.14.87 (2.365), 193.47.62.24 (2.263) e o endereço IPv6 2409:40d2:204e:4be:2a1f:f9c9:a055:e00b, com 1.953 ocorrências. A lista completa ainda traz 103.147.220.17 (1.860), 143.246.223.124 (1.791), 52.74.54.75 (1.260), 65.49.200.56 (836), 193.142.147.111 (775), 85.137.56.188 (672), 85.137.53.26 (664), 167.254.242.130 (648), 217.112.152.168 (619), 203.78.119.133 (616) e 140.245.32.169 (616).
Avaliação sobre o risco atual
A exploração bem-sucedida dessas falhas ainda depende fortemente da configuração específica do PHP, do SAPI em uso, das extensões carregadas, das classes da aplicação e do estado dos workers. No entanto, o tráfego observado está longe de ser formado apenas por sondagens genéricas ou malformadas. Trata-se, na verdade, de requisições construídas de forma proposital, combinando técnicas de pressão de memória, cadeias de gadgets com objetos serializados, marcadores de execução de comando e ações típicas de pós-exploração.
Apesar da sofisticação evidente desses payloads, sua presença isolada não comprova que os sites alvo tenham sido efetivamente comprometidos. Os dados das requisições demonstram, sim, intenção clara de executar comandos, roubar dados de configuração, instalar acesso persistente em PHP e buscar payloads adicionais. Diante desse cenário, a atualização imediata para as versões corrigidas do PHP segue sendo a medida mais eficaz para reduzir a exposição a essa onda de ataques direcionados.
Com informações de wordfence.com.
