Neste artigo do Blog Dolutech, vamos analisar o WordPress 7.1.2, lançado em 22 de setembro de 2026 como uma atualização de segurança exclusiva, apenas cinco dias depois do 7.1.1, que cobrimos aqui na semana passada. Diferente da liberação anterior, que trouxe 11 correções de segurança somadas a dezenas de ajustes de núcleo e do editor de blocos, o 7.1.2 é enxuto: uma única falha corrigida. O problema, porém, está entre os mais graves já tratados pelo WordPress em 2026, uma inclusão de arquivo local não autenticada na resolução de templates de página que, sob certas condições de servidor e de tema ativo, pode evoluir para execução remota de código (RCE).
Nós da Dolutech já vínhamos acompanhando o ritmo incomum de lançamentos de segurança do núcleo desde julho, quando publicamos nossa cobertura do wp2shell, a cadeia que forçou uma atualização automática obrigatória em instalações elegíveis. O 7.1.2 confirma que essa fase de escrutínio intenso sobre o núcleo do WordPress ainda não terminou, e neste artigo explicamos a falha, o que ela exige para virar RCE, o que mudou desde o 7.1.1, por que o núcleo do WordPress está recebendo tantos patches de segurança em sequência e, principalmente, o que administradores de sites precisam fazer agora.
O Que é a Falha do WordPress 7.1.2 (CVE-2026-87902)
A vulnerabilidade foi relatada de forma responsável por Robert Ressl e afeta o núcleo do WordPress desde a versão 4.7.0 até a 7.1.1, um intervalo que cobre praticamente uma década de lançamentos. Ela recebeu a identificação CVE-2026-87902, classificação CWE-98 (controle impróprio de nome de arquivo em uma instrução de inclusão) e pontuação CVSS 4.0 de 9,2, o que a coloca na faixa crítica. O vetor CVSS (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) resume bem o cenário: ataque pela rede, baixa complexidade, sem necessidade de privilégio ou de interação do usuário, e impacto alto em confidencialidade, integridade e disponibilidade quando a cadeia completa se realiza. O ponto que mais preocupa administradores é justamente a ausência de autenticação: não é preciso login, plugin vulnerável ou tema mal configurado para que o vetor de entrada exista.
Como a Falha Funciona na Prática
O problema está na função responsável por montar a lista de templates candidatos quando o WordPress renderiza uma página, dentro de wp-includes/template.php. Um dos candidatos é construído a partir da variável de consulta pagename, que vem diretamente da requisição HTTP feita pelo visitante. Nós explicamos o mecanismo em linguagem simples: o WordPress já validava, com a função interna validate_file(), um dos caminhos usados para montar o nome do arquivo de template, mas o caminho construído a partir de pagename decodificado via urldecode() não passava pelo mesmo filtro. Essa assimetria é o que abre a porta para inclusão de arquivo local.
Para efetivamente conseguir explorar isso, o nome do arquivo malicioso precisa continuar um diretório que comece literalmente com page- (porque é assim que o WordPress monta o nome candidato) e terminar em .php, já que a extensão é adicionada automaticamente pelo próprio código. Por isso, a precondição prática mais comum é um tema ativo que contenha um diretório de nível superior começando com page-, algo relativamente frequente em temas legados e em vários temas de terceiros populares.
O Que é Necessário Para Chegar à Execução de Código
Incluir um arquivo .php local não é, por si só, execução arbitrária de código escolhido pelo atacante: o servidor executa o que aquele arquivo já faz. Para transformar a inclusão em RCE de fato, o atacante precisa de um arquivo .php legível no servidor que se comporte de forma útil quando incluído. O candidato mais conhecido nesse tipo de cadeia é o pearcmd.php, do PEAR, que só se torna perigoso quando o PHP roda com a diretiva register_argc_argv habilitada. Essa configuração vem ativada por padrão em imagens Docker oficiais do PHP e em diversos ambientes cPanel com versões de PHP anteriores à 8.5, o que é mais comum do que se imagina.
Por isso, a leitura honesta da falha é condicional: a inclusão de arquivo não autenticada existe sempre que o núcleo estiver na versão vulnerável, mas a execução de código depende do alinhamento entre tema ativo e configuração de PHP do host. Como a Dolutech não tem como saber, à distância, se cada leitor está nesse cenário, o tratamento recomendado é simples: trate como crítico até confirmar o contrário no seu próprio ambiente.
A Correção Aplicada pelo WordPress
A equipe de segurança entregou duas mudanças no 7.1.2. A primeira fecha especificamente o buraco relatado, aplicando ao caminho derivado de pagename a mesma verificação validate_file() que o caminho irmão já possuía. A segunda é mais estrutural: o 7.1.2 introduz uma nova função de contenção que passa a validar todo template resolvido, não importa qual caminho de código o produziu, exigindo que o caminho final resolvido esteja dentro do diretório do tema ativo, do diretório de templates ou da pasta theme-compat. Nós interpretamos essa segunda mudança como um sinal de que a equipe de segurança tratou a resolução de templates como uma classe inteira de problema, e não apenas como um bug pontual, o que sugere que talvez não estivessem totalmente confiantes de que o caminho relatado por Ressl fosse o único vetor possível.
Relembrando o WordPress 7.1.1, Corrigido Cinco Dias Antes
Como comentamos na nossa cobertura anterior, o WordPress 7.1.1 saiu em 17 de setembro de 2026 como um lançamento combinado de manutenção e segurança: 17 correções de bugs no núcleo, cerca de 19 no editor de blocos e 11 correções de segurança. A falha mais séria daquela leva foi um XSS armazenado na função wpautop(), responsável por transformar quebras de linha em parágrafos, explorável por um visitante anônimo através de um comentário aprovado. As outras dez cobriam um path traversal autenticado no controlador REST de templates, sobrescrita arbitrária de posts por usuários com nível Contributor, instalação de temas via URLs manipuladas, um desvio de permissão via XML-RPC e diversos problemas de divulgação de informação.
Um detalhe que vale reforçar aqui: duas das 11 falhas do 7.1.1 foram relatadas pela própria Anthropic, criadora dos modelos Claude, o que reforça uma tendência que a Dolutech já vinha observando, o uso de ferramentas de análise automatizada e de IA para encontrar classes de vulnerabilidade como manipulação de dados não autorizada e path traversal em bases de código grandes e maduras como o núcleo do WordPress.
Se o seu site foi atualizado para o 7.1.1 na semana passada, isso não muda a urgência de aplicar o 7.1.2 agora: a CVE-2026-87902 afeta justamente as instalações que já estão no 7.1.1, já que a inclusão de arquivo local só foi fechada nesta última versão.
Quem Está em Risco: Versões Afetadas e Corrigidas
A falha atinge todo o núcleo do WordPress entre as versões 4.7.0 e 7.1.1. Como é uma questão presente há quase uma década de lançamentos, a equipe de segurança optou por fazer backport da correção para todos os ramos ainda elegíveis a receber patches, o que evita que sites em ramos antigos precisem de um salto de versão maior para se proteger.
| Ramo em uso | Versão corrigida |
|---|---|
| 7.1.x | 7.1.2 |
| 7.0.x | 7.0.6 |
| 6.9.x | 6.9.9 |
| 6.8.x | 6.8.10 |
| 6.7.x | 6.7.9 |
| Ramos anteriores, até 4.7 | Backport correspondente ao ramo |
Nós reforçamos um ponto que já repetimos em outras coberturas: se o seu painel ainda não oferece a atualização para o ramo correspondente, é possível que o backport daquele ramo específico ainda esteja em processo de publicação. Confira novamente em algumas horas em vez de presumir que o site está seguro.
Por Que o WordPress Está Tendo Tantas Falhas de Segurança Ultimamente?
Essa é a pergunta que mais recebemos de leitores nas últimas semanas, e é justo que seja feita. Olhando só para o calendário desde o lançamento da série 7.0, o ritmo realmente chama atenção:
| Data | Versão | Natureza do lançamento |
|---|---|---|
| 20 de maio | 7.0 | Lançamento principal |
| 9 de julho | 7.0.1 | Manutenção, 31 correções de bugs |
| 17 de julho | 7.0.2 | Segurança: cadeia de RCE não autenticada na API REST (o wp2shell), atualização forçada |
| 6 de agosto | 7.0.3 | Segurança: 12 correções |
| 12 de agosto | 7.0.4 | Segurança: RCE via processamento de imagem |
| 19 de agosto | 7.1 | Lançamento principal |
| 17 de setembro | 7.1.1 | Manutenção e segurança: 11 correções |
| 22 de setembro | 7.1.2 | Segurança: 1 falha crítica |
São cinco lançamentos de segurança do núcleo em 67 dias, totalizando 27 vulnerabilidades corrigidas no núcleo do WordPress só em 2026 até agora. Para efeito de comparação, o levantamento da Patchstack contabilizou seis vulnerabilidades de núcleo em todo o ano de 2025. A diferença é grande o suficiente para que a afirmação recorrente de que “o núcleo é estável, o problema são os plugins” já não descreva bem o que está acontecendo em 2026: o núcleo tem exigido atenção a cada duas semanas, em média, desde meados de julho.
Isso é um Sinal de Alarme ou de Maturidade?
Aqui vale um contraponto importante, que a Dolutech considera necessário trazer: encontrar vulnerabilidades não é, por si só, sinal de que um software piorou. É exatamente o oposto do que costuma acontecer quando ninguém está procurando. O WordPress move mais de 40% de todos os sites da internet, o que o torna um dos alvos mais estudados do mundo, tanto por atacantes quanto por pesquisadores de segurança legítimos. Os créditos dos últimos lançamentos repetem nomes como pwn.ai, Assetnote, Awesome Motive, a própria equipe de segurança do WordPress e, como vimos no 7.1.1, a Anthropic. Programas de bug bounty mais ativos, ferramentas de análise estática mais sofisticadas e, cada vez mais, uso de IA para varrer bases de código grandes em busca de padrões vulneráveis estão encontrando problemas que, em ciclos anteriores, poderiam ter permanecido escondidos por anos.
Isso não significa que o risco para quem administra um site seja menor. Significa que o risco está sendo descoberto e corrigido mais rápido, o que é bom no longo prazo, mas exige mais atenção no curto prazo. É perfeitamente normal, e esperado, que qualquer software de grande porte, ativamente mantido e amplamente auditado acumule vulnerabilidades ao longo do tempo. Nenhum sistema dessa escala é imune a isso, seja WordPress, um sistema operacional, um framework ou uma plataforma de e-commerce. O que diferencia um projeto maduro não é a ausência de falhas, mas a velocidade e a transparência com que elas são corrigidas, e nesse quesito o WordPress tem respondido rápido, inclusive com backports para ramos com quase dez anos de idade. Ainda assim, essa velocidade de correção só protege quem efetivamente aplica a atualização. Um patch disponível em um site desatualizado não protege ninguém.
Mapeamento MITRE ATT&CK
Para equipes de detecção e resposta, mapeamos a cadeia de exploração da CVE-2026-87902 às táticas e técnicas do MITRE ATT&CK, útil para orientar regras de SIEM e playbooks de resposta a incidentes.
| Tática | Técnica | ID MITRE |
|---|---|---|
| Reconhecimento | Varredura ativa de infraestrutura exposta | T1595 |
| Acesso Inicial | Exploração de aplicação voltada para o público | T1190 |
| Descoberta | Descoberta de arquivo e diretório (busca por PHP incluível) | T1083 |
| Execução | Interpretador de comandos e scripts | T1059 |
| Persistência | Web shell | T1505.003 |
| Escalonamento de Privilégio | Exploração para escalonamento de privilégio | T1068 |
| Evasão de Defesa | Arquivos ou informações ofuscadas | T1027 |
| Impacto | Manipulação de dados | T1565 |
Indicadores de Comprometimento (IoC)
Aqui a transparência é importante: nem a WordPress Security Team nem a Patchstack publicaram indicadores de comprometimento oficiais e específicos para a CVE-2026-87902 até o momento da publicação deste artigo, justamente para reduzir a janela de exposição de sites ainda não corrigidos. Qualquer lista neste estágio deve ser tratada como orientação geral de monitoramento, baseada no mecanismo conhecido da falha, e não como assinatura definitiva de comprometimento.
| Tipo de indicador | Descrição | Observação |
|---|---|---|
| Parâmetro de URL | Valores incomuns em pagename, especialmente contendo ../, %2e%2e, ou referências a pearcmd | Padrão associado ao mecanismo conhecido da falha |
| Estrutura de tema | Diretório de nível superior no tema ativo começando com page- | Precondição para exploração, não é indício isolado de ataque |
| Configuração de servidor | register_argc_argv habilitado no PHP | Precondição para RCE, verificável no próprio ambiente |
| Log de aplicação | Tentativas de inclusão de pearcmd.php ou caminhos fora do tema ativo | Consistente com tentativa de exploração da cadeia LFI-para-RCE |
| Arquivos suspeitos | Web shells com nomes ofuscados em diretórios de tema ou uploads | Padrão comum em campanhas pós-exploração contra WordPress |
Se sua equipe identificar qualquer um desses sinais combinados com uma versão vulnerável do WordPress, trate o incidente como comprometimento até prova em contrário, isole o servidor, preserve logs e inicie o processo de resposta a incidentes.
Como Corrigir: Atualização Imediata
Não existe mitigação temporária que substitua a atualização, e o processo é direto para quem administra o site pelo painel ou via linha de comando:
# Verificar a versão atual via WP-CLI
wp core version
# Atualizar para a versão mais recente corrigida do seu ramo
wp core update
# Confirmar que a atualização foi aplicada
wp core versionSites com atualizações automáticas de núcleo habilitadas devem receber o 7.1.2 (ou o backport do respectivo ramo) sem intervenção manual. Ainda assim, nós reforçamos o mesmo alerta de sempre: não presuma que a atualização automática funcionou. Confirme manualmente a versão em cada instalação sob sua responsabilidade, incluindo ambientes de homologação, subdomínios esquecidos e sites de clientes, já que atualizações automáticas podem ser silenciosamente desativadas por uma constante de configuração ou por uma pasta de controle de versão deixada no servidor.
Mitigação Temporária Para Quem Não Pode Atualizar Agora
Para ambientes onde a atualização imediata não é viável, por exemplo, sites com customizações extensas que exigem homologação antes do deploy em produção, duas verificações rápidas ajudam a entender a real exposição:
# Verificar se o tema ativo tem diretório de nível superior começando com "page-"
ls -la wp-content/themes/$(wp theme list --status=active --field=name)/ | grep "^d.*page-"
# Verificar se register_argc_argv está habilitado no PHP
wp eval "var_dump(ini_get('register_argc_argv'));"Nenhuma das duas é uma correção, mas ambas indicam o quão perto do pior cenário o ambiente está. Enquanto o núcleo não é atualizado, uma regra de bloqueio na camada de WAF reduz a superfície de ataque. Um exemplo de regra em Nginx, para ambientes que utilizam esse servidor como proxy reverso ou servidor direto:
# Bloqueia valores suspeitos no parâmetro pagename
if ($arg_pagename ~* "(\.\.|pearcmd|%2e%2e)") {
return 403;
}Se você utiliza soluções de firewall e prevenção de intrusão de código aberto, como BunkerWeb ou CrowdSec, o mesmo princípio se aplica: configure uma regra customizada para negar requisições cujo parâmetro pagename contenha sequências de travessia de diretório ou referências a pearcmd, e adicione o padrão às suas listas de bloqueio comportamental. Outra alternativa é adicionar uma camada de bloqueio diretamente na aplicação, via um mu-plugin simples que rejeita valores suspeitos antes que o WordPress tente resolver o template:
<?php
/**
* mu-plugin: bloqueio temporário para CVE-2026-87902
* Rejeita valores suspeitos no parâmetro pagename enquanto o núcleo não é atualizado.
*/
add_action( 'parse_request', function ( $wp ) {
if ( empty( $wp->query_vars['pagename'] ) ) {
return;
}
$pagename = $wp->query_vars['pagename'];
if ( false !== strpos( $pagename, '..' ) || false !== stripos( $pagename, 'pearcmd' ) ) {
wp_die( 'Requisição bloqueada por motivo de segurança.', 'Bloqueado', array( 'response' => 403 ) );
}
}, 1 );Trate essa medida como paliativa. Ela reduz a chance de exploração via o padrão de ataque conhecido, mas não substitui a atualização do núcleo, especialmente porque não temos garantia de que esse seja o único vetor possível dentro da classe de problema que o WordPress passou a tratar de forma estrutural no 7.1.2.
A Importância de Auditar os Plugins Instalados no Seu WordPress
Vale um parênteses importante neste artigo: embora a CVE-2026-87902 seja uma falha de núcleo, a grande maioria dos incidentes de segurança em WordPress, historicamente, continua vindo de plugins e temas, não do núcleo em si. É por isso que a Dolutech recomenda tratar a auditoria de plugins como rotina, e não como uma ação pontual disparada só depois de um incidente.
Na prática, isso significa revisar periodicamente cada plugin instalado e perguntar: ele ainda está em uso? Se não estiver, desative e remova, já que um plugin inativo continua sendo código executável no servidor e uma superfície de ataque válida. Ele ainda recebe atualizações? Plugins sem atualização há mais de um ano no repositório oficial do WordPress.org são um sinal de alerta, especialmente se o autor não responde mais a relatos de segurança. Ele tem um histórico de vulnerabilidades conhecidas? Bases como o WPScan Vulnerability Database, o Patchstack Vulnerability Database e o Wordfence Intelligence listam CVEs específicas por plugin e ajudam a decidir se vale a pena manter uma dependência ou substituí-la.
Evite também plugins “nulled”, cópias piratas de plugins pagos distribuídas fora dos canais oficiais. Além da questão de licenciamento, é uma prática recorrente entre atacantes embutir backdoors nesses arquivos, e nós já vimos casos assim em análises de comprometimento que a Dolutech conduziu. Por fim, teste atualizações de plugins críticos em um ambiente de homologação antes de aplicá-las em produção, já que uma atualização mal testada pode quebrar funcionalidades do site tanto quanto uma vulnerabilidade pode comprometê-lo.
Boas Práticas de Segurança Para WordPress
Reunimos aqui um checklist prático que a Dolutech recomenda para qualquer instalação WordPress, independentemente do tamanho do site:
- Mantenha atualizações automáticas de núcleo, temas e plugins habilitadas, mas confirme manualmente com alguma periodicidade que elas realmente aconteceram.
- Faça backups automáticos e testados, de arquivos e banco de dados, armazenados fora do próprio servidor de produção.
- Habilite autenticação multifator (2FA) para todas as contas com acesso administrativo.
- Utilize um firewall de aplicação web (WAF), seja na borda, como Cloudflare, seja localmente, como Coraza ou ModSecurity.
- Faça escaneamento de malware e integridade de arquivos com regularidade, não apenas quando o site já apresenta sintomas.
- Aplique o princípio do menor privilégio: cada usuário deve ter apenas o nível de acesso estritamente necessário para sua função.
- Desabilite a edição de arquivos pelo painel administrativo com a constante
DISALLOW_FILE_EDITnowp-config.php. - Proteja o
wp-config.phpe desative o XML-RPC caso ele não esteja em uso ativo por alguma integração. - Limite tentativas de login e utilize CAPTCHA ou verificação adicional em formulários de acesso.
- Mantenha um inventário atualizado de todos os plugins e temas instalados, removendo o que não está em uso.
- Use certificado SSL/TLS válido em toda a instalação e habilite HSTS.
- Monitore logs de acesso e de aplicação em busca de padrões anômalos, como os indicadores listados neste artigo.
Por Que Só Atualizar Não é Suficiente
Atualizar o núcleo, os temas e os plugins continua sendo a base de qualquer estratégia de segurança para WordPress, mas o ritmo de vulnerabilidades que vimos nas últimas semanas deixa um recado claro: depender apenas de patches reativos significa que existe sempre uma janela, entre a divulgação de uma falha e a atualização efetiva de cada instalação, em que o site fica exposto. É nessa janela que ferramentas de análise de segurança contínua fazem diferença, seja um scanner de vulnerabilidades, um WAF com regras atualizadas rapidamente, ou uma camada de monitoramento que sinaliza comportamento anômalo antes que ele vire incidente.
Existem hoje diversas plataformas voltadas a isso, cada uma com uma abordagem diferente: Wordfence e Sucuri são conhecidas por firewalls e scanners voltados especificamente ao ecossistema WordPress, enquanto soluções de EDR e MDR mais amplas, como Huntress ou Microsoft Defender, cobrem a infraestrutura ao redor do site. A própria Dolutech desenvolveu o SOC AI Agent, um binário standalone com WAF baseado em Coraza, pensado para funcionar como uma camada adicional de monitoramento e bloqueio em servidores que hospedam WordPress e outras aplicações web, complementando, e não substituindo, as práticas básicas de atualização e backup. Independentemente da ferramenta escolhida, o ponto que nós reforçamos é que ela precisa existir: confiar exclusivamente em “vou atualizar assim que perceber” deixa de ser uma estratégia viável em um cenário de cinco lançamentos de segurança de núcleo em pouco mais de dois meses.
Conformidade Regulatória
O impacto potencial de uma exploração bem-sucedida da CVE-2026-87902 não se limita à disponibilidade do site: execução remota de código pode expor dados pessoais armazenados na instalação, o que aciona obrigações regulatórias tanto no Brasil quanto na União Europeia e em Portugal.
No Brasil, sites que processam dados pessoais, como cadastros, formulários de contato ou dados de e-commerce, estão sujeitos à Lei Geral de Proteção de Dados (LGPD). Em caso de incidente de segurança que resulte em risco relevante aos titulares dos dados, a organização controladora deve avaliar a necessidade de comunicação à Autoridade Nacional de Proteção de Dados (ANPD) e, dependendo da gravidade, aos próprios titulares afetados.
Na Europa e em Portugal, o mesmo tipo de incidente pode acionar múltiplas obrigações simultâneas: o Regulamento Geral sobre a Proteção de Dados (GDPR), a diretiva NIS2 para operadores de serviços essenciais e importantes, e o DORA para entidades do setor financeiro. Empresas portuguesas devem também considerar a comunicação ao Centro Nacional de Cibersegurança (CNCS) e ao CERT.PT em cenários de incidente com potencial impacto relevante. Os prazos de notificação nesses regimes costumam ser curtos, geralmente contados em horas após a confirmação do incidente, o que torna a detecção precoce, discutida na seção de indicadores de comprometimento acima, ainda mais crítica.
Conclusão
O WordPress 7.1.2 corrige uma falha crítica, mas a história maior deste artigo do Blog Dolutech não é sobre uma única CVE. É sobre um núcleo que recebeu cinco atualizações de segurança em pouco mais de dois meses e 27 vulnerabilidades corrigidas em 2026, mais de quatro vezes o total registrado em todo o ano de 2025. Isso é normal para um software da escala e da maturidade do WordPress, e é, em boa parte, reflexo de um ecossistema de pesquisa de segurança mais ativo, incluindo o uso crescente de IA para encontrar classes inteiras de vulnerabilidade. Mas normal não é sinônimo de irrelevante: cada uma dessas correções só protege quem efetivamente as aplica.
A recomendação da Dolutech é direta: atualize para o 7.1.2 agora, confirme manualmente cada instalação sob sua responsabilidade, revise os plugins que estão realmente em uso no seu site e trate ferramentas de segurança contínua, como firewalls de aplicação e scanners de vulnerabilidade, como parte da rotina, não como resposta a um incidente já em curso. Se não for possível atualizar imediatamente, aplique o bloqueio temporário na camada de WAF descrito neste artigo enquanto o patch é validado em homologação, e não presuma que a atualização automática já resolveu o problema até confirmar manualmente.
Amante por tecnologia Especialista em Cibersegurança e Big Data, Formado em Administração de Infraestrutura de Redes, Pós-Graduado em Ciências de Dados e Big Data Analytics e Machine Learning, Com MBA em Segurança da Informação, Escritor do livro ” Cibersegurança: Protegendo a sua Reputação Digital”.