O WordPress 7.1.2 foi publicado como uma atualização de segurança para corrigir uma vulnerabilidade crítica na resolução de templates de página. A falha, registrada como CVE-2026-87902, pode permitir que um atacante sem autenticação faça o WordPress incluir um arquivo PHP local fora dos diretórios do tema ativo e, em determinadas configurações, chegue à execução remota de código.
Não é uma falha explorável da mesma forma em qualquer instalação. Ela depende de condições no tema e no servidor. Mesmo assim, o impacto possível é alto, não exige uma conta no site e recebeu nota 9,2 no CVSS 4.0. A recomendação oficial é atualizar imediatamente.
Onde está o problema
A vulnerabilidade está no caminho usado por get_page_template() para localizar o template de uma página. Um valor manipulado pode atravessar os limites esperados e apontar para um arquivo PHP legível em outra parte do servidor.
Incluir um arquivo local não produz execução de código automaticamente em todos os ambientes. O risco vira RCE quando também existe um arquivo PHP adequado no servidor e a configuração permite que essa inclusão seja aproveitada para executar comandos. É por isso que o aviso usa a expressão “RCE condicional”.
Quais instalações podem ser afetadas
Segundo o advisory do projeto, a exploração exige pelo menos estas condições:
- o tema pai ou filho ativo possui, no nível principal, um diretório cujo nome começa com
page-, comopage-templates; - existe no servidor um arquivo PHP escolhido pelo atacante e legível pela conta usada pelo servidor web;
- o ambiente fornece as condições adicionais necessárias para transformar a inclusão local em execução de código.
O comunicado cita os temas legados Twenty Twelve e Twenty Fourteen e também temas de terceiros como Neve, Hestia e Sydney como exemplos que atendem à primeira condição. Isso não significa que todo site usando esses temas tenha sido comprometido, nem que o tema seja sozinho a origem da falha. Significa que a estrutura dele pode completar uma das condições necessárias para explorar o problema no Core.
Versões corrigidas
A correção principal está no WordPress 7.1.2. O projeto também fez backport do patch para todas as linhas que ainda recebem correções de segurança, chegando até a versão 4.7. Entre as versões atualizadas estão 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12 e 6.4.12.
Sites em WordPress 7.1.0 ou 7.1.1 devem ir para 7.1.2. Quem permanece em uma linha anterior precisa instalar o patch correspondente, embora o próprio projeto lembre que apenas a versão mais recente recebe suporte ativo completo. Versões 4.6 e anteriores já não recebem esse backport.
O que fazer agora
- Confirme a versão instalada. Não presuma que a atualização automática já terminou em todos os ambientes.
- Atualize o Core. Prefira o WordPress 7.1.2; se uma migração de linha não for possível imediatamente, instale a versão corrigida correspondente.
- Verifique o resultado. Abra o painel, páginas públicas e rotas importantes depois da atualização, principalmente em instalações com cache persistente ou deploy customizado.
- Revise sinais fora do normal. Arquivos PHP desconhecidos, alterações inesperadas em temas ou plugins, novos usuários administrativos e eventos estranhos nos logs merecem investigação.
- Não trate a atualização como substituta de manutenção. Plugins, temas e credenciais também precisam continuar em dia.
Se o site permite atualizações automáticas em segundo plano, o processo pode ter começado sozinho. Ainda assim, vale conferir a versão efetivamente ativa, especialmente em ambientes gerenciados por Git, imagens de container ou pipelines que desabilitam alterações feitas pelo painel.
Por que a correção veio logo após o 7.1.1
O WordPress 7.1.1 havia saído poucos dias antes com correções de manutenção e segurança. A versão 7.1.2 é uma atualização separada, dedicada a esta nova vulnerabilidade crítica. Portanto, estar no 7.1.1 não resolve o problema descrito pelo CVE-2026-87902.
A combinação de acesso não autenticado, inclusão de arquivo PHP e impacto potencial de execução remota justifica a urgência, mesmo com pré-condições. Esperar para descobrir se uma instalação específica é explorável costuma custar mais tempo do que aplicar e validar um patch oficial já disponível.
