CVE-2026-87902: Falha Crítica no Core do WordPress Permite Execução Remota de Código Não Autenticada sob Certas Condições

O WordPress lançou uma atualização de segurança emergencial para abordar uma vulnerabilidade crítica em seu software Core que pode permitir que um atacante não autenticado carregue arquivos PHP locais arbitrários e, em condições específicas de servidor e tema, consiga execução remota de código. Rastreada como CVE-2026-87902, a vulnerabilidade afeta as versões do WordPress da 4.7.0 até a 7.1.1 e tem uma pontuação CVSS 4.0 de 9.2.

A falha reside na resolução de templates de página do WordPress. Um atacante pode manipular o valor que o WordPress usa ao selecionar um template de página e fazer com que get_page_template() inclua um arquivo PHP legível fora dos diretórios do tema ativo. Não é necessário ter conta no WordPress, cookie de autenticação, interação do administrador ou plugin vulnerável para o ataque subjacente de inclusão de arquivos.

A execução remota de código é condicional, em vez de universal. O tema ativo deve conter uma estrutura de diretório compatível, e o servidor deve expor um arquivo PHP legível adequado que possa ser explorado quando incluído. O ataque demonstrado publicamente usou o pearcmd.php do PEAR em um ambiente onde a configuração register_argc_argv do PHP estava habilitada.

O WordPress lançou a versão 7.1.2 em 22 de setembro de 2026, especificamente para resolver a vulnerabilidade e fez o backport das correções para os ramos de segurança mantidos desde o WordPress 4.7. Os administradores de sites são fortemente aconselhados a atualizar imediatamente.

Contate Vendas

Análise da CVE-2026-87902

A vulnerabilidade tem origem em como o WordPress Core resolve templates para páginas. Quando um visitante solicita uma página, o WordPress constrói uma lista de nomes de arquivos de templates potenciais e busca no tema ativo um arquivo correspondente.

Em versões vulneráveis, os dados controlados pelo atacante usados durante este processo não são suficientemente restringidos antes de serem incorporados ao caminho do template da página. Um pedido elaborado pode, portanto, introduzir sequências de travessia de diretórios e fazer com que o WordPress resolva um arquivo PHP que reside fora dos diretórios esperados do tema ativo.

A principal informação sobre a CVE-2026-87902 é que o primitivo central é a inclusão de arquivos locais, não a execução incondicional de código arbitrário. O WordPress descreve oficialmente o problema como permitindo que um atacante não autenticado faça com que a resolução de templates de página inclua um arquivo .php local legível fora dos diretórios do tema. A execução remota de código só se torna possível quando pré-requisitos ambientais adicionais são satisfeitos.

Um tema vulnerável deve conter um diretório de nível superior cujo nome comece com page-, como:

page-templates

O aviso do WordPress identifica os temas legados Twenty Twelve e Twenty Fourteen entre aqueles que atendem a este requisito estrutural. Temas populares de terceiros, como Neve, Hestia e Sydney, também podem conter layouts de diretórios compatíveis.

Uma segunda condição é que o atacante deve identificar um arquivo PHP local legível pela conta do servidor web que produza um comportamento útil quando incluído.

O pesquisador de segurança Robert Ressl demonstrou o caminho para execução remota de código usando um componente PEAR chamado pearcmd.php. Para que essa técnica funcione, a opção register_argc_argv do PHP também deve estar habilitada. A imagem oficial do Docker do PHP pode atender às condições relevantes, enquanto configurações tradicionais do cPanel usando versões do PHP antes da 8.5 também podem expor o ambiente necessário.

Essa distinção é importante porque nem toda instalação vulnerável do WordPress pode ser explorada imediatamente para execução de código arbitrário. Um site pode conter o código Core vulnerável, mas não ter a estrutura de tema ou o ambiente PHP necessário para a cadeia de exploração demonstrada.

No entanto, o próprio primitivo de inclusão de arquivos locais cruza um limite importante de segurança e não requer autenticação ou interação do usuário.

CVE-2026-87902 afeta WordPress Core da versão 4.7.0 a 7.1.1. O aviso oficial lista os ramos vulneráveis individualmente, incluindo:

• WordPress 7.1.0–7.1.1
• WordPress 7.0.0–7.0.5
• WordPress 6.9.0–6.9.8
• WordPress 6.8.0–6.8.9
• WordPress 6.7.0–6.7.8
• WordPress 6.6.0–6.6.8
• Todas as ramificações afetadas correspondentes até o WordPress 4.7.36

O WordPress 7.1.1, lançado apenas cinco dias antes como uma atualização de segurança, continua vulnerável a este problema separado.

A vulnerabilidade foi descoberta pelo pesquisador de segurança Robert Ressl e relatada de forma privada através do programa HackerOne do WordPress em 20 de julho de 2026. O WordPress reconheceu o relatório em 21 de julho e informou o pesquisador em 15 de setembro que um conserto estava planejado. O patch e o aviso público foram lançados em 22 de setembro.

O WordPress classifica a vulnerabilidade como Crítica com uma pontuação CVSS 4.0 de 9.2. Seu vetor reflete um ataque de acesso à rede de baixa complexidade, sem privilégios exigidos e sem interação do usuário, enquanto também registra que requisitos adicionais de ataque devem estar presentes antes que o impacto máximo demonstrado seja possível.

Um PoC CVE-2026-87902 público foi lançado pelo pesquisador junto com a divulgação. O proof of concept inclui um laboratório local reproduzível e demonstra o caminho de uma travessia de template não autenticada para inclusão de PHP local e execução remota de código condicional. O pesquisador testou o exploit contra o WordPress 7.0.2 em ambientes isolados e não o testou em sites de produção ao vivo.

A execução bem-sucedida no ambiente demonstrado ocorreu com os privilégios da conta do PHP/servidor web, identificada como www-data, em vez de fornecer automaticamente privilégios de root do sistema operacional. O impacto prático, portanto, depende em parte das permissões atribuídas ao processo do servidor web.

Um atacante que alcança a execução de código PHP poderia potencialmente implantar um web shell, modificar arquivos do site, roubar dados de configuração do WordPress e credenciais de banco de dados, criar persistência, alterar conteúdo, redirecionar visitantes ou usar o site comprometido como uma base inicial para ataques adicionais. Esses são resultados potenciais pós-exploração em vez de atividades atualmente atribuídas a uma campanha CVE-2026-87902 no mundo real.

No momento da divulgação inicial em 22 de setembro, nenhuma exploração no ambiente real havia sido relatada e o registro de enriquecimento da CISA listou a exploração como inexistente.

No entanto, o cenário de ameaças começou a mudar dentro de horas após a divulgação. A Patchstack relatou ter detectado tentativas de sondagem por volta de 17:44 UTC em 22 de setembro, menos de cinco horas depois que o WordPress 7.1.2 se tornou disponível. As solicitações observadas corresponderam à codificação abordada pelo patch, sugerindo uma análise rápida da diferença de segurança.

Importante, a Patchstack caracterizou o tráfego observado como sondagem em vez de entrega bem-sucedida de payload. As solicitações tentaram incluir arquivos PHP Core do WordPress comuns e não demonstraram execução de código controlado pelo atacante. Até 23 de setembro, as evidências publicamente disponíveis, portanto, apoiam o reconhecimento ativo, mas não a exploração bem-sucedida confirmada em ambientes de produção.

Atualmente, não há IOCs da CVE-2026-87902 específicos de campanha como domínios maliciosos, hashes de arquivo, famílias de malware ou um conjunto definitivo de infraestrutura do atacante. Os defensores devem, em vez disso, se concentrar em padrões de solicitações HTTP associadas à travessia anormal de templates de página e subsequente atividade de sistema de arquivos ou PHP.

Os sinais de alerta potenciais incluem:

• Solicitações contendo sequências de travessia de diretórios codificadas ou repetidas
• Solicitações tentando manipular a seleção de templates de página
• Padrões de acesso envolvendo nomes de arquivos PHP locais inesperados
• Novos arquivos PHP aparecendo em diretórios do WordPress escrevíveis
• Processos filhos inesperados lançados pela conta do PHP ou servidor web
• Conexões de saída inexplicáveis originando-se de trabalhadores PHP
• Novas contas de administrador ou alterações não autorizadas ao conteúdo do WordPress
• Modificações em temas, plugins ou arquivos Core após solicitações HTTP suspeitas

Como informações públicas de exploração estão agora disponíveis, as organizações devem esperar uma varredura mais ampla e desenvolvimento automatizado de exploit, embora uma violação real bem-sucedida não tenha sido confirmada publicamente.

Mitigação da CVE-2026-87902

A principal remediação é instalar imediatamente uma versão corrigida do WordPress. O WordPress afirma que o ramo mais recente, WordPress 7.1.2, contém a correção de segurança, e versões corrigidas também foram criadas para ramos mais antigos.

As versões corrigidas oficiais incluem:

• 7.1 → 7.1.2
• 7.0 → 7.0.6
• 6.9 → 6.9.9
• 6.8 → 6.8.10
• 6.7 → 6.7.9
• 6.6 → 6.6.9
• 6.5 → 6.5.12
• 6.4 → 6.4.12
• 6.3 → 6.3.12
• 6.2 → 6.2.13
• 6.1 → 6.1.14
• 6.0 → 6.0.16

Os backports de segurança continuam através do WordPress 4.7.37. O WordPress enfatiza, no entanto, que apenas a versão mais recente do WordPress é ativamente suportada, então a atualização para o ramo atual é preferível onde operacionalmente viável.

Sites que suportam atualizações automáticas em segundo plano devem começar a receber a versão de segurança automaticamente. Os administradores podem verificar e instalar manualmente a atualização através de:

Painel do WordPress → Atualizações → Atualizar Agora

O WordPress não fornece uma solução completa que substitua a instalação da atualização de segurança.

Detecção da CVE-2026-87902 deve começar com a identificação de todas as instalações do WordPress que estejam rodando versões Core 7.1.1 ou anteriores e então determinar se o tema pai ou filho ativo contém um diretório de nível superior começando com page-.

Os administradores também devem determinar se o PHP está rodando com:

register_argc_argv = On

e se componentes do PEAR legíveis, como pearcmd.php ou outros potenciais pontos de entrada PHP locais úteis, existem no servidor. Essas verificações ajudam a avaliar a exposição a técnicas conhecidas de execução remota de código, mas não determinam se a falha subjacente do WordPress existe.

To Para detectar a sondagem ou tentativa de exploração da CVE-2026-87902, as equipes de segurança devem inspecionar a telemetria do servidor web, WAF, proxy reverso, PHP e WordPress em busca de:

• Padrões de travessia codificados ../ ou equivalente em solicitações frontais
• Solicitações que tentam manipular a resolução de templates de página do WordPress
• Referências incomuns a arquivos .php fora dos diretórios do tema ativo
• Solicitações tentando alcançar componentes PHP relacionados ao PEAR
• Rajadas de solicitações de travessia semelhantes de uma fonte
• Trabalhadores PHP lançando inesperadamente comandos de shell ou utilitários do sistema
• Novos arquivos PHP ou web shells aparecendo após solicitações suspeitas
• Mudanças inesperadas no wp-config.php, temas, plugins ou uploads
• Novas contas de administrador do WordPress
• Tráfico de saída suspeito originando-se do servidor web

As varreduras observadas pela Patchstack mostram que sites do WordPress expostos à internet já podem receber sondas específicas de vulnerabilidade, tornando a telemetria web e WAF particularmente valiosa para investigação retrospectiva.

Administradores que não puderem corrigir imediatamente podem reduzir a exposição à cadeia de execução baseada em PEAR demonstrada desativando register_argc_argv para solicitações web quando não for necessário e removendo componentes do PEAR web-legíveis não utilizados. Robert Ressl ressalta que estas são apenas medidas de endurecimento; elas não corrigem a vulnerabilidade subjacente do WordPress.

As organizações também podem reduzir o impacto potencial de pós-exploração, garantindo que a conta PHP/servidor web siga os princípios de menor privilégio. Não deve ter acesso de gravação desnecessário a diretórios do sistema ou arquivos de aplicativos sensíveis.

Sites que eram acessíveis pela internet antes de serem corrigidos devem ser revistos quanto a solicitações suspeitas a partir em torno da divulgação pública de 22 de setembro, particularmente porque o material de PoC público se tornou disponível ao mesmo tempo e a sondagem seguiu dentro de horas.

Se for identificada exploração suspeita, os administradores devem preservar logs relevantes e realizar uma revisão completa da integridade de:

• Arquivos Core do WordPress
• Temas ativos e inativos
• Plugins
• O diretório de uploads
• wp-config.php
• Configuração do servidor web
• Tarefas agendadas e entradas de cron
• Contas de administrador do WordPress
• Processos PHP e arquivos criados recentemente

Senhas de banco de dados potencialmente expostas, chaves de API, segredos de aplicativos ou outras credenciais armazenadas em arquivos legíveis devem ser rotacionadas se a investigação indicar que um atacante conseguiu inclusão de arquivo local ou execução de código.

A prioridade imediata continua sendo a atualização do próprio WordPress. Alterações de tema, desativação do PEAR, ou modificação das configurações do PHP podem reduzir alguns caminhos de exploração, mas não devem ser tratadas como substitutos para a versão oficial de segurança.