Resumo para quem decide

A CVE-2026-87902 no WordPress, uma vulnerabilidade crítica no núcleo da plataforma, está sendo explorada ativamente desde poucas horas após o lançamento do patch. O fabricante classifica a falha como Critical, CVSS v4 9.2. Ela afeta todas as versões do WordPress entre 4.7.0 e 7.1.1, o que cobre praticamente qualquer instalação que não tenha sido atualizada nos últimos anos.

A exploração exige duas condições no ambiente: um tema ativo com diretório de nome começando com page- (caso de temas legados como Twenty Twelve e Twenty Fourteen, e de temas de terceiros populares como Neve, Hestia e Sydney) e a presença de um arquivo pearcmd.php legível no servidor. Quando as duas condições coexistem, um atacante não autenticado consegue executar código remotamente.

A recomendação é direta: atualizar para WordPress 7.1.2, ou para a versão corrigida correspondente à sua branch (a lista completa está mais abaixo). A vulnerabilidade já foi incluída no catálogo CISA KEV em 25 de setembro de 2026, com prazo de correção para agências federais americanas até 28 de setembro. Existem PoCs públicas, template Nuclei e user-agents de ferramentas automatizadas circulando. Se seu ambiente usa algum dos temas ou configurações citadas abaixo, tratar isso como prioridade máxima de patch é justificado.

O que é a CVE-2026-87902 e por que ela é crítica

A CVE-2026-87902 foi registrada pelo próprio time de segurança do WordPress, no advisory GHSA-7hp8-65ch-5whp, descoberta e reportada de forma responsável por Robert Ressl. A classificação de fraqueza é CWE-98, controle impróprio de nome de arquivo em instrução include/require de programa PHP, o que na prática é uma inclusão de arquivo local (LFI).

O produto afetado é o WordPress Core, não um plugin ou tema isolado. Isso muda a escala do problema: qualquer instalação rodando uma versão entre 4.7.0 e 7.1.1 está potencialmente vulnerável, independentemente de quais plugins estejam instalados.

Severidade: CVSS 9.2 (v4) ou 8.1 (v3.1)? Entendendo a divergência

Vale registrar uma divergência de pontuação entre fontes, porque ela ilustra algo comum em avaliação de risco: o fabricante pontua a falha em CVSS v4 9.2, com Attack Complexity classificado como Low. Já a Previdian, ao reportar a mesma CVE, usa CVSS v3.1 e chega a 8.1, com Attack Complexity High.

A diferença não é um erro, é metodológica. CVSS v4 mudou a forma de calcular alguns componentes e separa melhor pré-condições de ambiente (o campo “Attack Requirements: Present” no relatório do fabricante já sinaliza isso) do que a complexidade de ataque em si. Na prática, isso significa que times de segurança que consomem feeds de vulnerabilidade de fontes diferentes podem ver números distintos para a mesma CVE e precisam entender de onde vem cada pontuação antes de usá-la para priorizar patches. Esse tipo de nuance também aparece na discussão sobre como métricas complementares, como o EPSS, ajudam a calibrar a probabilidade real de exploração além do CVSS puro, tema que já tratamos no post sobre as vantagens do EPSS em um relatório de pentest.

A própria Previdian registra EPSS de 18,2% para esta CVE, um dado que ajuda a contextualizar a probabilidade de exploração em massa, independente do CVSS escolhido.

O mecanismo do ataque: path traversal em get_page_template()

O núcleo do problema está na função get_page_template(), responsável por resolver qual arquivo de template usar para exibir uma página. Segundo a análise técnica da Patchstack, o slug da página passa por um sanitizador do WordPress que preserva octetos escapados (percent-encoding) enquanto reescreve pontos literais e trunca em barras literais. O efeito colateral é que um payload de traversal de diretório precisa vir codificado (por exemplo, usando %252f) para escapar da sanitização, sendo decodificado depois, já dentro da função vulnerável.

O resultado é que um atacante não autenticado consegue forçar a inclusão de um arquivo .php local, fora dos diretórios de tema ativos, desde que ele seja legível pela conta do servidor web. Um detalhe operacional: a requisição precisa incluir um page_id válido junto com o pagename malicioso. Sem um page_id que aponte para uma página real, a query retorna 404 antes de alcançar o código vulnerável, o que os atacantes claramente já mapearam nos ataques observados.

Pré-requisitos que transformam a falha em RCE real

O advisory do fabricante é explícito: a CVE-2026-87902 sozinha não gera execução remota de código. Duas condições de ambiente precisam estar presentes simultaneamente.

Temas vulneráveis com diretórios page-*

A primeira condição é que o tema filho ou pai ativo tenha um diretório de topo cujo nome comece com page- (por exemplo, page-templates). Isso afeta temas legados incluídos no próprio WordPress, como Twenty Twelve e Twenty Fourteen, além de temas de terceiros com ampla base instalada: Neve, Hestia e Sydney.

Esse é um bom exemplo de como um componente de terceiro, neste caso um tema, amplia a superfície de ataque de uma falha que, isoladamente, seria apenas teórica. É a mesma lógica que discutimos ao falar sobre risco de dependências de terceiros em ataques de cadeia de suprimentos: a vulnerabilidade nasce no núcleo, mas sua explorabilidade real depende de decisões de terceiros sobre estrutura de diretórios de temas amplamente distribuídos.

O gadget pearcmd.php e o papel do register_argc_argv

A segunda condição é a presença de um arquivo .php alvo que sirva de gadget para execução de código. O caso documentado é o pearcmd.php, componente do PEAR (PHP Extension and Application Repository) que muitas distribuições de PHP incluem por padrão. Esse gadget vira um caminho para execução de código quando a diretiva register_argc_argv está ligada (On) no PHP.

Isso não é um caso raro: a imagem oficial do PHP para Docker é afetada, e a configuração padrão do cPanel também é vulnerável quando usa versões do PHP anteriores à 8.5. Os locais observados sendo testados pelos atacantes são /usr/local/lib/php/pearcmd.php, /usr/share/php/pearcmd.php e /usr/share/pear/pearcmd.php.

Vale destacar que desabilitar register_argc_argv não corrige o path traversal em si, mas quebra a cadeia de exploração via pearcmd, reduzindo o impacto de execução de código para vazamento de informação. É uma mitigação parcial, não um substituto do patch.

Linha do tempo da exploração da CVE-2026-87902 no WordPress: do patch ao CISA KEV em dias

A velocidade com que a CVE-2026-87902 foi armada é o ponto mais didático do caso. O patch foi lançado em 22 de setembro de 2026 e, no mesmo dia, às 11:49 UTC, a Patchstack já registrava a primeira tentativa de exploração. Os sensores da Previdian registraram a primeira tentativa em 23 de setembro.

Nos dias seguintes o volume cresceu de forma irregular mas consistente. Dados da Previdian mostram contagem diária de eventos: 0 em 22 de setembro, 138 em 23, 12 em 24, 118 em 25, 139 em 26, um salto para 690 em 27 de setembro e 57 em 28 de setembro. Até 28 de setembro, os sensores da Previdian somavam 1.154 tentativas, vindas de 11 IPs únicos em 9 países. Esse é o recorte da rede de sensores de uma empresa, não o tamanho total da campanha: a Patchstack relata que o tráfego, que na primeira noite saía de um pequeno grupo de endereços, já se espalhou por algumas centenas.

A CVE-2026-87902 entrou no catálogo CISA KEV em 25 de setembro, apenas três dias após o patch, com prazo de correção para agências federais americanas até 28 de setembro. Nesse intervalo curtíssimo também surgiram PoCs públicas no GitHub (a primeira registrada pela Pruva já em 22 de setembro, mesmo dia do patch) e um template Nuclei dedicado, detectado em 24 de setembro.

Esse tipo de compressão da janela entre patch e exploração em massa não é exclusividade do WordPress. Vimos padrão semelhante, embora em outro contexto de produto e superfície de ataque, no caso do zero-day do BIG-IP APM da F5 já explorado antes de correção ampla. A lição prática se repete: o tempo disponível entre “patch disponível” e “exploração em produção contra sua infraestrutura” está cada vez mais curto, e processos de gestão de patches que dependem de janelas de manutenção mensais já não são suficientes para falhas críticas com PoC pública.

Indicadores de comprometimento e detecção em três estágios

Nos ataques à CVE-2026-87902, a Patchstack documentou o comportamento dos atacantes em três estágios bem definidos, o que dá material concreto para quem quer caçar essa atividade nos próprios logs antes mesmo de confirmar comprometimento.

Padrões de requisição (reconhecimento, checagem do pearcmd, escrita de arquivo)

No primeiro estágio, o atacante testa se a inclusão funciona apontando para arquivos core inofensivos do próprio WordPress, como wp-links-opml.php, wp-includes/feed-rss2.php, wp-cron.php, wp-includes/functions.php, wp-login.php ou install.php. O padrão de requisição observado tem a forma:

GET /?page_id=<id válido>&pagename=templates%252f<traversal>wp-links-opml

No segundo estágio, o atacante verifica se o pearcmd.php está acessível, usando o parâmetro +config-show na query string, o que explora diretamente o comportamento do register_argc_argv:

GET /?page_id=<id válido>&pagename=templates%2f<traversal>usr%2flocal%2flib%2fphp%2fpearcmd&+config-show

No terceiro estágio, havendo confirmação de que o gadget funciona, o atacante escreve um arquivo PHP arbitrário em disco usando +config-create:

GET /?page_id=<id válido>&pagename=templates%2f<traversal>pearcmd&+config-create+<payload PHP>+/tmp/<nome>.php

Um detalhe operacional relevante: o método POST superou o GET em frequência nos ataques observados, porque o WordPress lê o parâmetro pagename do corpo da requisição de forma preferencial. Isso significa que regras de detecção baseadas apenas em query string de GET vão perder parte do tráfego malicioso. A Patchstack também observou variação de profundidade de traversal (de 1 a 12 níveis), hex maiúsculo e minúsculo, encoding simples e duplo, e requisições indo tanto para /index.php quanto para a raiz do site.

IoCs: arquivos, IPs, user-agents e sinais de exploração bem-sucedida

Para busca em logs, os indicadores de alta confiança listados pela Patchstack incluem: parâmetro pagename contendo %2e%2e ou %252e%252e; valor de pagename começando com templates%2f ou outro nome de diretório page-; pagename e page_id aparecendo juntos na raiz do site ou em /index.php; qualquer requisição contendo pearcmd, +config-show ou +config-create.

Dois user-agents de ferramentas automatizadas foram identificados circulando: cve-2026-87902-poc/1.0 e nuclei-cve-2026-87902/1.0.

No nível de arquivo, a Previdian e o The Hacker News reportam nomes observados após escrita bem-sucedida: wp-pear-rce-flag.php, poc87902.php, e variações com nomes aleatórios como luci_<random>.php e zeta_<random>.php. A Patchstack notou dois comportamentos distintos entre os payloads escritos: alguns depositam apenas strings marcadoras inofensivas (como CVE-2026-87902-POC-OK ou uma versão ofuscada montada via chamadas chr()), típico de quem está apenas catalogando hosts vulneráveis; outros escrevem uma tag curta que executa comando shell ao ser acessada, o que já é exploração ativa, não pesquisa.

A Previdian também identificou requisições contra sua rede de honeypots originadas de um IP em Nova Jersey, Estados Unidos (104.194.9[.]227), que incluem o arquivo local /usr/local/lib/php/pearcmd.php, escrevem um arquivo em /tmp/ e em seguida incluem um script de upload PHP hospedado no GitHub, em raw.githubusercontent[.]com/MrG3P5/web-shell/refs/heads/main/uploader.php. Parte da atividade também se originou de um IP na Indonésia. Outros IPs associados aos ataques, segundo o The Hacker News e a Patchstack, incluem 43.250.53[.]42, 180.251.159[.]243, 195.178.110[.]247, 107.189.14[.]87, 45.61.184[.]170 e 92.246.130[.]76. Eles servem para busca em logs, não como defesa: com o tráfego distribuído por centenas de endereços, a própria Patchstack avisa que bloquear origens uma a uma não é estratégia.

Um sinal indireto também vale checar em logs históricos: se alguma URL de página normal do seu site retornou 200 OK com conteúdo de OPML ou RSS no corpo, isso indica que um probe de estágio 1 funcionou contra seu ambiente antes do patch ser aplicado, e vale investigar se os estágios seguintes também ocorreram.

No nível do host, verifique /tmp e /var/tmp por arquivos .php inesperados, incluindo os nomes citados acima. A Patchstack pondera que um arquivo isolado em /tmp normalmente não é acessível via web, então por si só é prova de execução, não necessariamente um backdoor persistente. Ainda assim, a presença desse arquivo indica que o host foi comprometido do ponto de vista do atacante, e merece resposta a incidente completa, não apenas remoção do arquivo.

Como corrigir e mitigar

A correção oficial é atualizar o WordPress para a versão 7.1.2. Para quem está em branches mais antigas, o fabricante retroportou o patch como cortesia até a versão 4.7.37, cobrindo praticamente todo o histórico de versões afetadas. As versões corrigidas por branch são: 7.1.2, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32 e 4.7.37.

Se a atualização imediata não for possível, a Patchstack recomenda um workaround simples: rejeitar sequências de traversal no parâmetro pagename, já que um slug de página real nunca contém esse padrão. Esse bloqueio pode ser aplicado sem afetar tráfego legítimo. Desabilitar register_argc_argv no PHP também reduz o impacto, quebrando a cadeia via pearcmd, embora não corrija o path traversal em si.

Essa situação, patch disponível mas com janela real de exposição antes da atualização em toda a base instalada, se repete em outros componentes críticos amplamente usados: a velocidade de aplicação do patch em produção é o fator que realmente determina se uma CVE crítica vira um incidente ou apenas uma linha em um relatório de scanner.

Depois de atualizar, vale auditar sinais de atividade maliciosa anterior usando os IoCs listados acima, já que o patch corrige a vulnerabilidade daqui para frente mas não remove artefatos deixados por uma exploração que já tenha ocorrido antes da atualização.

Vale notar que, segundo o CEO da Previdian, Ryan Dewhurst, mesmo com a gravidade da falha, as pré-condições de ambiente tornam a exploração menos provável em instalações que não usam os temas ou configurações citadas. Como o WordPress tem atualização automática habilitada por padrão em muitas instalações, é esperado ver um volume alto de tentativas de exploração em massa, mas um número bem menor de comprometimentos reais bem-sucedidos.

Perguntas frequentes

Minha instalação WordPress está automaticamente vulnerável à CVE-2026-87902 só por estar desatualizada?
Não necessariamente. A falha exige duas condições simultâneas no ambiente: um tema ativo com diretório de nome começando com page- e um arquivo PHP gadget, como o pearcmd.php, acessível e legível pelo servidor web com register_argc_argv ligado. Sem essas duas condições, a vulnerabilidade de path traversal existe no código mas não se converte em execução remota de código.

Como sei se meu tema é vulnerável à CVE-2026-87902?
Verifique se o tema ativo (filho ou pai) tem algum diretório de topo cujo nome comece com page-. Os casos documentados incluem os temas legados Twenty Twelve e Twenty Fourteen, além dos temas de terceiros Neve, Hestia e Sydney.

Atualizar o WordPress sozinho já resolve o problema?
Sim, para a vulnerabilidade em si. Atualizar para 7.1.2 (ou a versão corrigida da sua branch) elimina a falha de path traversal na origem. Mas se seu site já foi comprometido antes da atualização, o patch não remove arquivos maliciosos deixados por um atacante, por isso a auditoria de IoCs em /tmp, /var/tmp e nos logs de acesso continua sendo necessária.

Por que a mesma CVE aparece com notas de gravidade diferentes em fontes distintas?
Porque o fabricante usa CVSS v4 (nota 9.2) enquanto a Previdian reporta CVSS v3.1 (nota 8.1) para a mesma falha. As duas versões do CVSS calculam complexidade de ataque de forma diferente, e o CVSS v4 do fabricante já embute o conceito de pré-condições de ambiente em um campo separado (Attack Requirements), o que explica parte da divergência numérica.

Existe proteção via firewall de aplicação enquanto o patch não é aplicado?
Clientes da Patchstack contam com uma regra de virtual patch proprietária (RapidMitigate). A Previdian, por sua vez, informa que não tinha um virtual patch disponível no momento da publicação de sua análise, com regras para ModSecurity, Cloudflare e AWS WAF planejadas para lançamento futuro. Na ausência de proteção via WAF, o workaround de bloquear sequências de traversal no parâmetro pagename é a alternativa mais direta até a atualização ser aplicada.