WordPress corrige falha crítica que carrega PHP sem autenticação

WordPress↳WordPress9 conteúdosAndroid push notifications com Quasar Framework, Firebase e integração com WordPressDev (Back & Front) · mai 2019Simplificando a acessibilidade de documentos: introduzindo a integração do ONLYOFFICE DocSpace com WordPress e DrupalDev (Back & Front) · abr 2024Como criar seu site WordPress com um único prompt de IA em minutos?Dev (Back & Front) · mar 2025Ver tudo em Dev (Back & Front) → lançou a versão 7.1.2 em 22 de setembro para corrigir a CVE 2026 87902. A falha recebeu nota CVSS 9.2 no aviso oficial. O problema mora no núcleo da plataforma, e não em plugin ou tema.

A brecha permite que um atacante sem login manipule a resolução de modelos de página. Com isso, o sistema tenta incluir um arquivo PHP local escolhido por ele.

Em certas combinações de tema e servidor, o cenário evolui para execução remota de código. Portanto, a atualização virou prioridade imediata.

WordPress falhava ao validar o caminho do template

O mecanismo afetado decide qual arquivo PHP renderiza cada página. Essa lógica precisa atender estruturas de tema variadas, inclusive modelos personalizados.

A validação do caminho, porém, deixava passar entradas manipuladas. No entanto, o padrão envolvido segue o formato page-{valor}.php.

Assim, a manipulação permitia escapar da pasta esperada do tema. Em seguida, o fluxo alcançava outro arquivo PHP existente no sistema.

Além disso, a correção reforçou justamente essa checagem. Segundo análise da Patchstack, a versão corrigida passou a confirmar com rigor se o caminho resolvido pertence aos diretórios autorizados.

O crédito da descoberta vai para o pesquisador Robert Ressl, que fez divulgação responsável junto ao projeto.

As duas condições que levam até execução de código no WordPress

A exploração completa depende de pré requisitos. O primeiro está no tema ativo.

O tema pai ou filho precisa ter um diretório de nível superior começando com page-. O aviso cita exemplos como Twenty Twelve, Twenty Fourteen, Neve, Hestia e Sydney.

O segundo requisito mora no servidor. Além disso, precisa existir um arquivo PHP local legível pelo usuário do servidor web e alcançável pela falha.

Essa distinção importa para o inventário. Contudo, confiar na ausência dessas condições funciona mal como estratégia de defesa.

O PHP entra na cadeia com register_argc_argv

Uma configuração específica eleva bastante o impacto. Trata se da diretiva register_argc_argv.

Quando ela está habilitada, o arquivo pearcmd.php pode participar da cadeia. Nesse caso, a inclusão de arquivo local vira execução de código.

Contudo, vale a ressalva técnica. O PEAR aparece como peça da cadeia, enquanto a causa segue na resolução de template.

O relatório aponta ambientes de risco conhecidos. Configurações oficiais de PHP em Docker↳Docker46 conteúdosE o Docker Swarm? Contextos e motivadores diáriosDevSecOps · ago 2024Automatizando o ambiente de desenvolvimento e testes com DockerDevSecOps · mai 2019MySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Ver tudo em DevSecOps → e instalações padrão do cPanel com PHP anterior ao 8.5 podem apresentar as condições relevantes.

WordPress publicou correção até o ramo 4.7

A série atual recebe o 7.1.2. Além disso, o projeto liberou correções retroativas para ramos antigos ainda suportados.

Alguns exemplos da lista: 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9 e 6.5.12. A cadeia segue até o 4.7.37.

As versões 4.6 e anteriores ficaram de fora. Elas já perderam o suporte de segurança.

Vale o lembrete do projeto. Apenas a versão mais recente é considerada ativamente suportada.

Como aplicar a correção agora

Pelo painel, o caminho é curto. Acesse Painel e depois Atualizações, então clique em Atualizar agora.

Antes disso, garanta backup recente do banco e dos arquivos. Sites com atualização automática talvez já tenham recebido o patch, ainda assim confirme a versão manualmente.

No terminal, o WP CLI resolve rápido. Use wp core version para conferir, wp core check-update para verificar e wp core update para aplicar.

Depois, confirme a versão novamente. Em produção, mantenha o procedimento controlado, com validação e testes posteriores.

O que revisar depois do patch

Comece pelos logs de acesso. Procure requisições incomuns ligadas à resolução de páginas ou a arquivos PHP fora do fluxo normal.

A urgência tem motivo. Segundo a Patchstack, sondagens contra sites começaram poucas horas após a publicação da correção.

Uma tentativa de sondagem, por si só, prova pouco. Contudo, sinais suspeitos pedem investigação mais ampla.

Nessa checagem, olhe arquivos modificados, usuários administrativos desconhecidos, plugins e temas alterados, tarefas agendadas e processos do usuário do servidor web.

Vale também revisar o ambiente PHP. Verifique register_argc_argv, a versão em uso e arquivos PHP locais desnecessários e acessíveis.

O ponto que agências e times de hospedagem precisam tratar

Quem administra muitos sites tem trabalho extra. Revise o inventário completo, incluindo instalações antigas e esquecidas.

Em hospedagem compartilhada, a checagem cobre todos os sites sob administração. Afinal, o site menos importante abre a mesma porta que o principal.

Acompanhe nosso perfil no Instagram!