Esta é uma explicação rápida sobre uma vulnerabilidade que está sendo explorada ativamente (listada no KEV da CISA). Ela cobre o que acontece, quem é afetado e como responder — do lado do defensor, sem passos de reprodução.
- CVE
- CVE-2026-87902 (GHSA-7hp8-65ch-5whp)
- Severidade
- NVD: CVSS v3.1 8,1 (complexidade de ataque alta) / Aviso da WordPress: CVSS v4.0 9,2, Crítica
- Tipo
- Inclusão de arquivo (CWE-98) — path traversal na resolução de template de página
- Impacto
- Inclusão de arquivos .php fora do tema; RCE quando as condições do tema e do servidor se alinham
- Pré-condições
- Sem autenticação, sem interação do usuário
- Afetados
- WordPress 4.7.0–7.1.1
- Correção
- 7.1.2, lançada em 22 de setembro de 2026, com correções para todos os ramos até a 4.7
- Exploração
- No KEV da CISA (adicionado em 25 de setembro de 2026, prazo de correção em 28 de setembro), sinalizado como exigindo triagem forense
Quão perigoso é esperar?
O WordPress é o CMS mais usado, e esta falha abrange cerca de dez anos de lançamentos, sem autenticação e sem interação do usuário. Uma empresa de segurança focada em WordPress relata que a sondagem começou no dia em que a correção foi lançada, passou a tentativas de execução de código no dia seguinte e foi incorporada a ferramentas de varredura de uso geral. A varredura é indiscriminada; o tamanho do seu site é irrelevante.
Que tipo de falha é?
O WordPress decide qual arquivo de template renderiza uma página procurando-o nos diretórios do tema. Segundo o aviso, essa resolução de template de página tinha uma brecha: um invasor não autenticado poderia fazer com que ela incluísse um arquivo .php fora dos diretórios do tema ativo. Quando um valor externo decide qual arquivo será carregado, isso é inclusão de arquivo (CWE-98). Este site não descreve como ela é explorada.
Por si só, isso não é execução de código. O aviso divide as condições para o RCE em um lado do tema e um lado do servidor.
Condição do lado do tema (segundo o aviso)
- O tema pai ou filho ativo tem um diretório de primeiro nível cujo nome começa com
page-(por exemplo,page-templates) - O aviso diz que isso se aplica aos temas legados Twenty Twelve e Twenty Fourteen e a alguns temas populares de terceiros, como Neve, Hestia e Sydney (a falha está no tratamento do núcleo, não nos temas)
Condição do lado do servidor (segundo o aviso)
- Existe no servidor um arquivo .php que se comporta de forma perigosa quando incluído e é legível pela conta do servidor web
- O
register_argc_argvativado do PHP torna essa condição bem mais fácil de atender - O aviso diz que a imagem Docker oficial do PHP e a configuração padrão do cPanel com PHP anterior à 8.5 são afetadas
① Falha no núcleo: .php fora do tema pode ser incluído
→ corrigida na 7.1.2 (e na versão de cada ramo)
② Condição do tema: um diretório começando com page-
→ difícil de saber por conta própria; não conte com essa avaliação
③ Condição do servidor: um .php perigoso é legível e register_argc_argv está ativado
→ desativar a configuração impede toda a classe de ataque
Quem é afetado
| Ramo | Afetadas | Corrigido |
|---|---|---|
| 7.1 | 7.1.0–7.1.1 | 7.1.2 |
| 7.0 | 7.0.0–7.0.5 | 7.0.6 |
| 6.9 | 6.9.0–6.9.8 | 6.9.9 |
| 6.8 | 6.8.0–6.8.9 | 6.8.10 |
| 6.7 até 4.7 | até a versão anterior à correção de cada ramo | correção de cada ramo (6.7.9 … 4.7.37) |
| Anteriores à 4.7 | — | Sem correção (sem suporte) |
O que fazer
Verifique sua versão e migre para a versão corrigida (prioridade máxima)
No painel, vá em Painel → Atualizações e verifique a versão. Se não for a 7.1.2 (ou a versão corrigida do seu ramo), atualize hoje. Apenas a versão mais recente é ativamente suportada, então a 7.1.2 é o alvo mais seguro.
Encontre os sites que as atualizações automáticas não alcançam
Em sites que suportam atualizações em segundo plano, a atualização começa sozinha. O risco está nos sites fora desse caminho: atualizações automáticas desativadas, núcleo fixado no Git ou em imagem de contêiner (se você atualizar e depois reconstruir, a versão antiga volta sem aviso), atualizações bloqueadas pelo host e o site antigo que ninguém lembra. Se você administra vários sites, verifique cada um (lista de verificação de inventário de segurança).
Desative o register_argc_argv do PHP (defesa em profundidade)
O PHP que atende requisições web quase nunca precisa dessa configuração. Defina register_argc_argv = Off no php.ini (ou nas configurações de PHP do seu host); se você usa contêineres, verifique a configuração da imagem. Isso não substitui a atualização, mas corta uma rota de inclusão de arquivo para execução de código que vai muito além desta CVE.
Verifique se você foi invadido antes de atualizar
Se um site permaneceu sem correção após 22 de setembro, trate esse período como suspeito; a CISA também sinaliza esta CVE para triagem forense. No mínimo, verifique: (1) arquivos .php desconhecidos em /tmp, /var/tmp ou dentro de wp-content; (2) requisições nos logs de acesso contendo travessia de diretório codificada em percent-encoding (o equivalente a ../); (3) usuários administradores ou plugins adicionados recentemente que você não reconhece.
Se algo parecer errado, não pare em 'corrigido'
Se código pode ter sido executado, a correção não remove arquivos já colocados no servidor nem chaves já roubadas. Troque a senha do banco de dados e as chaves de autenticação/salts em wp-config.php, as senhas de administrador e as chaves de API de terceiros, e remova os arquivos suspeitos. O processo completo está em o playbook de remediação de vulnerabilidades e em segurança do WordPress.
Visão deste site: assim que uma correção é publicada, os ataques começam imediatamente
No caso recente do Adobe Commerce, passaram-se 44 dias entre a correção e o KEV. Aqui foram três. A diferença está em quão facilmente o diff da correção revela o ataque e em quantos sites usam o produto. Segundo a cronologia relatada, a sondagem no formato do diff começou no mesmo dia em que a correção foi lançada.
A lição: para um produto amplamente usado, a correção não dá tempo extra. Os atacantes começam a trabalhar nela no momento em que ela é publicada, e é difícil para as pessoas acompanharem isso manualmente. Por isso este site coloca a garantia de que as atualizações automáticas realmente cheguem acima do próprio processo de correção. Sites que receberam a atualização automática estavam protegidos antes de os proprietários saberem de algo. Os sites em risco são aqueles que não percebem que estão fora das atualizações automáticas.
Mais um ponto: o EPSS era de 3%. O EPSS é útil, mas fica atrasado para falhas recém-divulgadas. Quando KEV e EPSS divergem, siga o KEV — ele é o fato confirmado.
Fontes
- WordPress — GHSA-7hp8-65ch-5whp (versões afetadas e corrigidas, pré-condições do RCE, CVSS v4.0 9,2)
- WordPress.org — WordPress 7.1.2 Release (22 de setembro de 2026; backports até 4.7, atualizações automáticas)
- NVD — CVE-2026-87902 (CWE-98, CVSS v3.1 8.1)
- CISA KEV — Known Exploited Vulnerabilities Catalog (adicionado em 25 de setembro de 2026, prazo em 28 de setembro, triagem forense exigida)
- FIRST — EPSS (0,029 em 25 de setembro de 2026)
- Relatório de observação — Patchstack (sondagem a partir do dia da correção, tentativas de execução de código no dia seguinte; este artigo usa apenas a cronologia e as verificações do lado do defensor)
Leia a seguir
- Prática: Segurança do WordPress / O playbook de remediação de vulnerabilidades
- Decisão: Priorizando com CVSS, EPSS e KEV
- O caso contrastante: CVE-2026-71362 (Adobe Commerce: KEV 44 dias após a correção)
- Termos: O que é RCE? / O que é path traversal?