A vulnerabilidade WordPress identificada como CVE-2026-87902 começou a ser sondada poucas horas depois da publicação da correção. O problema, classificado como crítico, permite inclusão local de arquivos sem autenticação e pode levar à execução condicional de código. A primeira atividade foi registrada em 22 September 2026, 17:44 UTC.
Vulnerabilidade WordPress entrou na mira de atacantes
A falha afeta versões do WordPress entre 4.7.0 e 7.1.1. O risco recebeu nota CVSS 9.2 (Critical), e a exploração observada até o momento consiste em sondagens para identificar instalações expostas, não em uma campanha comprovada de execução de código.
As primeiras requisições chegaram aos registros menos de cinco horas depois do lançamento do WordPress 7.1.2. Os dados indicam que os responsáveis pelos testes provavelmente analisaram a diferença entre a versão vulnerável e o código corrigido, já que os formatos enviados correspondem exatamente ao mecanismo tratado pelo patch.
Até agora, os pedidos apontaram a inclusão para arquivos comuns do núcleo, como:
- wp-links-opml.php
- wp-includes/functions.php
- wp-cron.php
Esses arquivos não permitem, por si só, a execução de código controlado pelo invasor. No entanto, o retorno de wp-links-opml.php produz um documento OPML característico. Dessa forma, o atacante consegue confirmar se a inclusão funcionou e se o servidor está vulnerável.
Como os testes são enviados
Uma requisição desativada, sem fornecer um payload funcional, segue este formato:
GET /?page_id=<valid page id>&pagename=templates%252f<traversal>wp-links-opml
O uso de dupla codificação é um dos principais sinais. O WordPress passa o slug por um sanitizador que preserva octetos codificados, mas altera pontos literais e interrompe o processamento em barras literais. Por isso, uma sequência simples como ../../ não sobrevive ao fluxo, enquanto a versão codificada é posteriormente decodificada por get_page_template().
Outro indicador importante é a presença simultânea dos parâmetros page_id e pagename. O primeiro precisa apontar para uma página válida; caso contrário, o WordPress retorna erro 404 e o código vulnerável não é alcançado. Assim, essa combinação é incomum no tráfego normal e pode ajudar na identificação da vulnerabilidade WordPress em registros antigos.
Os pesquisadores também observaram variações nos pedidos, incluindo:
- Profundidade de travessia entre três e sete níveis;
- Hexadecimais em maiúsculas, como %252F%252E%252E, além das versões em minúsculas;
- Requisições POST e GET;
- Acessos direcionados tanto à raiz do site quanto diretamente a /index.php.
Endereços associados à atividade
A atividade partiu de um pequeno grupo de endereços que acessou vários sites protegidos. A maior parte do volume ficou concentrada nos seguintes IPs:
- 169.58.48.193
- 169.58.48.195
- 2001:df1:e8c0::106b
A maioria das requisições usou o agente Go-http-client/1.1, enquanto uma parcela menor apresentou identificadores falsos de navegadores. O movimento atingiu o pico na primeira hora e diminuiu depois, comportamento compatível com uma varredura oportunista de uma lista de hosts, e não necessariamente com um ataque direcionado.
Correção e sinais de detecção
A correção indicada para a vulnerabilidade WordPress é a atualização para 7.1.2. O reparo também foi disponibilizado nas versões 7.0.6, 6.9.9, 6.8.10 e em backports até 4.7.37. Portanto, sites antigos podem instalar a versão corrigida de sua própria linha sem precisar saltar para uma versão principal mais recente.
Enquanto a atualização não for possível, bloquear sequências de travessia no parâmetro pagename funciona como medida provisória. Um slug legítimo de página não contém esse tipo de sequência, o que reduz o risco de impacto sobre o tráfego normal.
Na investigação dos logs, os sinais de maior valor são:
- pagename contendo %252e%252e na URL ou no corpo POST;
- Valores iniciados por templates%252f ou por outro diretório page-;
- page_id e pagename usados juntos na raiz do site ou em /index.php;
- Retorno de OPML ou de outro arquivo do núcleo em uma URL comum de página.
Um retorno 200 com conteúdo OPML no lugar de uma página indica que a inclusão foi bem-sucedida. Nesse cenário, a vulnerabilidade WordPress deve ser tratada como uma exposição confirmada, e não apenas como uma tentativa bloqueada. Além disso, é recomendável revisar registros históricos e verificar arquivos inesperados ou alterados.
Linha do tempo da vulnerabilidade WordPress
Em 22 September 2026, o WordPress 7.1.2 foi lançado e o aviso GHSA-7hp8-65ch-5whp foi publicado. Na mesma data, a falha foi adicionada ao banco de vulnerabilidades da Patchstack, que informou a implantação de uma regra RapidMitigate para sites protegidos.
Também em 22 September 2026, 17:44 UTC, foi observada e bloqueada a primeira tentativa de exploração. O monitoramento continua concentrado na possibilidade de os testes deixarem de mirar arquivos comuns do núcleo e passarem a usar alvos capazes de produzir efeitos mais graves.
