Quando alguém abre uma página de um site, o WordPress precisa decidir qual arquivo do tema será usado para exibi-la. É uma tarefa comum, daquelas que acontecem milhares de vezes sem que o visitante perceba.
Mas, na falha identificada como CVE-2026-87902, uma informação enviada na requisição podia interferir nessa escolha de um jeito perigoso.
Em determinadas condições, uma pessoa sem login conseguia induzir o WordPress a carregar um arquivo PHP localizado fora das pastas do tema.
Imagine pedir ao sistema a página de um site e fazê-lo procurar o arquivo em outro lugar do servidor. Essa é a essência da falha: uma inclusão de arquivo local causada por um caminho que não recebeu a validação necessária. Dependendo do arquivo alcançado e da configuração do servidor, o problema pode chegar à execução de código.
Onde o caminho saiu do controle
Para montar uma página, o WordPress considera diferentes nomes de arquivo até encontrar o modelo adequado. Um desses nomes era construído a partir de pagename, informação que podia vir da requisição.
Na versão vulnerável, esse caminho era decodificado e entrava na lista de possíveis modelos sem passar pela mesma verificação aplicada a outro caminho próximo no código.
Isso permitia uma técnica chamada travessia de diretórios: manipular o caminho de um arquivo para sair da pasta onde o programa deveria procurar.
A exploração ainda dependia de condições específicas, entre elas uma estrutura compatível no tema ativo. Portanto, estar em uma versão afetada exige atenção, mas não significa que todo site pudesse ser comprometido da mesma forma.
Há mais um detalhe decisivo. Carregar um arquivo PHP fora do tema já é uma quebra de segurança, mas executar código escolhido pelo invasor exige uma combinação adicional.
A Patchstack descreveu uma possibilidade envolvendo o arquivo pearcmd.php, quando ele está disponível no servidor e uma configuração específica do PHP está habilitada.
É por isso que o risco de execução de código é condicional, embora a vulnerabilidade tenha sido classificada como crítica.
Da descoberta aos ataques em poucas horas
O WordPress lançou a versão 7.1.2 em 22 de setembro de 2026 para corrigir a falha. No mesmo dia, às 11h49 UTC, a Patchstack registrou a primeira tentativa de exploração em seu firewall.
Os acessos iniciais buscavam descobrir se os sites respondiam ao carregamento indevido de arquivos comuns do WordPress. Era a etapa de reconhecimento: encontrar portas abertas antes de tentar atravessá-las.
A atividade avançou rapidamente. A Patchstack passou a observar tentativas de alcançar o pearcmd.php e de gravar arquivos PHP no servidor.
Alguns arquivos continham marcadores usados para confirmar que o teste funcionou; outros traziam conteúdo preparado para executar comandos.
A empresa também identificou ferramentas públicas de varredura e informou que o volume de requisições cresceu mais de dez vezes em relação à primeira noite. São observações feitas no tráfego monitorado pela Patchstack, não uma estimativa de quantos sites foram comprometidos.
O que fazer se você administra um site
A correção está no WordPress 7.1.2 e também foi disponibilizada para versões anteriores ainda elegíveis a atualizações de segurança. O próprio projeto recomenda atualizar os sites imediatamente. O primeiro passo, portanto, é conferir a versão instalada e aplicar a versão corrigida correspondente.
A atualização resolve a falha daqui para a frente. Se o site ficou exposto, também vale olhar para trás: revisar os registros de acesso e procurar arquivos PHP inesperados nas pastas temporárias do servidor.
Uma tentativa registrada não prova que o ataque funcionou. Já evidências de que um arquivo foi carregado indevidamente, ou de que um novo arquivo PHP foi gravado, pedem investigação do ambiente.
O episódio mostra como uma decisão discreta, escolher o arquivo que exibe uma página, pode se tornar um problema grande quando recebe um caminho indevido.
Para o visitante, a página parecia apenas uma página. Para quem procurava a falha, ela podia ser a entrada para outro lugar do servidor.
