A vulnerabilidade crítica no WordPress identificada como CVE-2026-87902 coloca administradores de sites diante de um cenário que exige atenção imediata. A falha permite que um invasor não autenticado manipule a resolução de modelos de página para fazer o WordPress tentar incluir um arquivo PHP local escolhido pelo atacante. Em determinadas combinações de tema e configuração do servidor, isso pode evoluir para execução remota de código (RCE).
O problema foi corrigido no WordPress 7.1.2, lançado em 22 de setembro de 2026, e também recebeu correções retroativas para os ramos suportados até a série 4.7. A própria equipe de segurança do projeto recomenda a atualização imediata, justamente porque a falha está no núcleo da plataforma e pode ser explorada sem autenticação quando as condições necessárias estão presentes.
Neste artigo, vamos entender como funciona a CVE-2026-87902, por que determinadas configurações do PHP aumentam o risco, quais versões estão vulneráveis e o que administradores de servidores Linux, desenvolvedores e usuários do WordPress devem fazer agora.
Entendendo a vulnerabilidade crítica no WordPress
A CVE-2026-87902 está relacionada à função responsável pela resolução de modelos de página do WordPress. Segundo o aviso oficial, um atacante não autenticado pode manipular essa resolução para fazer o sistema incluir um arquivo PHP local legível pelo usuário do servidor, mesmo quando esse arquivo está fora dos diretórios normalmente permitidos para temas.
O problema é classificado como crítico, com CVSS 9.2 no aviso de segurança do WordPress. A falha foi reportada pelo pesquisador Robert Ressl, que realizou a divulgação responsável junto ao projeto.
Há uma particularidade importante: a vulnerabilidade não significa que todo WordPress desatualizado possa ser convertido automaticamente em RCE. A exploração depende de condições específicas no tema ativo e no ambiente PHP.
Ainda assim, a possibilidade de exploração sem necessidade de login torna a atualização uma prioridade.
Como a manipulação de modelos de página abre brechas
O WordPress possui mecanismos para determinar qual arquivo PHP deve ser utilizado para renderizar determinada página. Essa lógica precisa trabalhar com diferentes estruturas de temas, incluindo modelos personalizados.
Na vulnerabilidade descoberta, a validação do caminho utilizado durante essa resolução não impedia adequadamente determinados caminhos manipulados pelo atacante.
O cenário envolve o padrão de resolução associado a nomes como page-{valor}.php. Em determinadas circunstâncias, a manipulação do caminho permite escapar da localização esperada dos arquivos de tema e alcançar outro arquivo PHP existente no sistema.
A correção introduzida pelo WordPress reforça justamente essa validação. A análise técnica da Patchstack aponta que a versão corrigida passou a verificar de forma mais rigorosa se o caminho resolvido realmente pertence aos diretórios autorizados do tema.
Isso transforma uma falha aparentemente relacionada apenas à localização de templates em um problema potencialmente muito mais grave.
Condições necessárias para a execução remota de código
A vulnerabilidade no WordPress possui alguns pré-requisitos que determinam se o cenário pode chegar efetivamente à execução de código.
O primeiro está relacionado ao tema ativo. O aviso oficial informa que o tema pai ou filho precisa conter um diretório de nível superior cujo nome comece com page-. O relatório cita, entre outros exemplos, temas como Twenty Twelve, Twenty Fourteen, Neve, Hestia e Sydney.
O segundo requisito está no próprio servidor: precisa existir um arquivo PHP local legível pelo usuário do servidor web que possa ser alcançado pela falha.
Essa distinção é importante para administradores. Um WordPress vulnerável em termos de versão não significa necessariamente que o site esteja imediatamente sujeito ao mesmo caminho de exploração até RCE. Porém, não é recomendável depender da ausência desses requisitos como estratégia de defesa.
O problema está no core do WordPress, e a correção oficial já está disponível.
O papel do PHP na vulnerabilidade crítica no WordPress
Um dos elementos que pode elevar significativamente o impacto da falha é a configuração register_argc_argv do PHP.
Essa diretiva controla a disponibilidade dos argumentos de linha de comando nas variáveis relacionadas a scripts PHP. Em determinados ambientes, principalmente instalações mais antigas ou configurações específicas, ela pode estar habilitada.
O aviso técnico do WordPress aponta que o conhecido arquivo pearcmd.php, associado ao ecossistema PEAR, pode participar de uma cadeia que transforma a inclusão de arquivo local em execução de código quando register_argc_argv está habilitado. O relatório também observa que determinadas configurações oficiais de PHP em Docker e instalações padrão do cPanel com PHP anterior ao 8.5 podem apresentar as condições relevantes.
Isso não significa que PEAR seja a causa da vulnerabilidade. O problema fundamental está na forma como o WordPress realiza a resolução do template e permite alcançar um arquivo PHP fora dos diretórios esperados.
O componente PEAR aparece como uma possível peça na cadeia de exploração.
Como reduzir temporariamente a exposição
A medida correta continua sendo atualizar o WordPress. Alterar configurações do PHP não substitui o patch.
Entretanto, enquanto uma atualização estiver sendo planejada ou testada, administradores podem verificar:
- se o tema ativo possui diretórios de nível superior iniciados por
page-; - se
register_argc_argvestá habilitado; - qual versão do PHP está sendo utilizada;
- se existem arquivos PHP locais desnecessários e acessíveis pelo usuário do servidor web;
- se o ambiente utiliza configurações específicas de cPanel, Docker ou outras plataformas de hospedagem.
A própria Patchstack recomenda verificar essas condições para determinar a exposição, mas reforça que elas devem ser tratadas como informações para avaliação de risco, e não como substituição da atualização.
Versões corrigidas e como atualizar seu ambiente
O WordPress 7.1.2 é a versão corrigida para quem está no ramo atual. A equipe do projeto também disponibilizou correções para os ramos antigos que ainda recebem atualizações de segurança.
As versões corrigidas são:
| Ramo afetado | Versão corrigida |
|---|---|
| WordPress 7.1 | 7.1.2 |
| WordPress 7.0 | 7.0.6 |
| WordPress 6.9 | 6.9.9 |
| WordPress 6.8 | 6.8.10 |
| WordPress 6.7 | 6.7.9 |
| WordPress 6.6 | 6.6.9 |
| WordPress 6.5 | 6.5.12 |
| WordPress 6.4 | 6.4.12 |
| WordPress 6.3 | 6.3.12 |
| WordPress 6.2 | 6.2.13 |
| WordPress 6.1 | 6.1.14 |
| WordPress 6.0 | 6.0.16 |
| WordPress 5.9 | 5.9.18 |
| WordPress 5.8 | 5.8.17 |
| WordPress 5.7 | 5.7.19 |
| WordPress 5.6 | 5.6.21 |
| WordPress 5.5 | 5.5.22 |
| WordPress 5.4 | 5.4.23 |
| WordPress 5.3 | 5.3.25 |
| WordPress 5.2 | 5.2.28 |
| WordPress 5.1 | 5.1.26 |
| WordPress 5.0 | 5.0.29 |
| WordPress 4.9 | 4.9.33 |
| WordPress 4.8 | 4.8.32 |
| WordPress 4.7 | 4.7.37 |
As versões 4.6 e anteriores não recebem mais atualizações de segurança. O projeto também ressalta que somente a versão mais recente, atualmente 7.1.2, é considerada ativamente suportada.
Atualização pelo painel do WordPress
Para a maioria dos administradores, o procedimento mais simples é acessar o painel administrativo e abrir Painel > Atualizações.
Se a atualização estiver disponível, selecione Atualizar agora. Antes disso, em ambientes de produção, é recomendável garantir que exista um backup recente e funcional do banco de dados e dos arquivos do site.
Sites configurados para receber atualizações automáticas em segundo plano podem já ter iniciado o processo. Mesmo assim, é importante confirmar manualmente a versão instalada depois da atualização.
Atualização usando WP-CLI
Em servidores Linux administrados por terminal, o WP-CLI permite verificar e atualizar o núcleo do WordPress sem depender da interface gráfica.
Primeiro, confirme a versão instalada:
wp core versionDepois, verifique se há uma atualização disponível:
wp core check-updateEm um ambiente preparado para receber a correção, a atualização do core pode ser executada com:
wp core updateDepois, confirme novamente:
wp core versionEm servidores de produção, a atualização deve fazer parte de um procedimento controlado, com backup, validação do ambiente e testes posteriores.
O que verificar depois da atualização
A instalação do patch deve ser acompanhada por uma verificação básica de segurança.
Confirme se o WordPress está efetivamente executando uma das versões corrigidas. Depois, revise os registros de acesso do servidor em busca de requisições incomuns relacionadas à resolução de páginas ou tentativas de acessar arquivos PHP que normalmente não fazem parte do fluxo do site.
A Patchstack informou que começou a observar sondagens contra sites WordPress poucas horas depois da publicação da correção, indicando que administradores devem considerar a possibilidade de varreduras automatizadas após a divulgação pública da falha.
Encontrar uma tentativa de sondagem não prova, por si só, que houve comprometimento. Porém, se houver sinais suspeitos, vale ampliar a investigação para arquivos modificados, usuários administrativos desconhecidos, plugins ou temas alterados, tarefas agendadas e processos executados pelo usuário do servidor web.
Considerações finais e recomendações de segurança
A CVE-2026-87902 demonstra novamente por que o gerenciamento de atualizações precisa ser tratado como parte essencial da administração de servidores WordPress.
Embora a exploração até RCE dependa de uma combinação específica de tema, arquivos locais e configuração do PHP, o fato de a falha permitir acesso não autenticado ao mecanismo de resolução de templates torna a situação relevante para qualquer administrador que mantenha uma instalação vulnerável.
O caminho mais seguro é direto: verifique a versão do WordPress agora e instale a atualização correspondente ao seu ramo. Para instalações modernas, isso significa migrar para o WordPress 7.1.2.
Também vale revisar a configuração do PHP, principalmente em servidores antigos ou ambientes que utilizam configurações padronizadas de hospedagem, e manter temas, plugins, PHP e componentes do sistema operacional atualizados.
A vulnerabilidade crítica no WordPress já possui correção oficial. O maior risco, neste momento, é permanecer com uma versão vulnerável quando o patch já está disponível.
Administradores de sistemas e profissionais responsáveis por múltiplos sites também devem verificar seus inventários para garantir que nenhuma instalação antiga tenha ficado esquecida. Em ambientes corporativos ou de hospedagem compartilhada, essa checagem deve ser feita em todos os sites sob administração, não apenas na instalação considerada mais importante.
Por fim, compartilhar este alerta com outros administradores, desenvolvedores e responsáveis por servidores pode ajudar a reduzir a janela de exposição enquanto a comunidade aplica as correções.
