CVE-2026-87902 no WordPress Core: path traversal sem login pode levar a RCE

A CVE-2026-87902 é uma vulnerabilidade crítica de path traversal e inclusão local de arquivo PHP no WordPress Core. Um visitante sem login pode fazer a resolução de templates sair dos diretórios do tema ativo e incluir um arquivo PHP legível no servidor. Quando o tema e o ambiente oferecem as pré-condições necessárias, a cadeia termina em execução remota de código e comprometimento completo do site.

O que aconteceu

O caminho vulnerável começa em get_page_template(), que usa o valor público pagename para montar um candidato como page-{nome}.php. A entrada já havia sido decodificada pela requisição, mas era processada novamente com urldecode(). Uma sequência duplamente codificada podia se transformar em componentes de travessia somente dentro da resolução do template.

Em seguida, locate_template() verificava a existência do caminho concatenado, mas não garantia que o destino canônico permanecesse dentro do tema permitido. A correção agora rejeita a travessia com validate_file() e adiciona uma segunda barreira que resolve e valida o caminho antes da inclusão. A primeira mudança fecha o vetor conhecido e a segunda protege outros chamadores e filtros.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

A inclusão local é alcançável sem autenticação, mas a transição para RCE exige duas condições: o tema pai ou filho ativo deve possuir diretório de nível superior iniciado por page-, e o usuário do servidor web deve conseguir ler um arquivo PHP local com comportamento útil quando incluído. O advisory cita Twenty Twelve, Twenty Fourteen, Neve, Hestia e Sydney como exemplos de layout, sem declarar que toda versão desses temas seja explorável.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Crítico — CVSS v4.0 9,2 no advisory; CVSS 3.1 8,1 na avaliação secundária. A diferença de notas decorre das métricas e das pré-condições de ambiente, não de uma contradição no impacto. O ataque parte da internet, não requer conta nem clique, e pode alcançar RCE. Sites sem a combinação necessária podem não oferecer execução imediata, mas continuam com o path traversal no Core e podem se tornar exploráveis após mudanças de tema, PHP ou pacotes.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Confirme a versão por ramo, o tema pai/filho ativo e a existência de diretórios superiores page-*. Avalie a configuração do PHP web, não apenas a CLI. Faça somente inventário: não construa URL de travessia nem tente incluir arquivos em produção.

wp core version --extra
wp core check-update
wp core verify-checksums
wp theme list --status=active --fields=name,status,version,update,update_version
find wp-content/themes -mindepth 2 -maxdepth 2 -type d -name 'page-*' -print
php -r 'echo PHP_VERSION, " register_argc_argv=", ini_get("register_argc_argv"), PHP_EOL;'

Não use a regra simplificada “7.1.1 ou anterior”: os backports possuem números menores e já são corrigidos. Compare cada ramo com a tabela. Diretório page-* indica uma pré-condição, não exploração. A CLI pode usar php.ini diferente do PHP-FPM/LSAPI; confira a configuração efetiva pelo painel ou diagnóstico protegido.

Como corrigir ou mitigar

Atualize preferencialmente para WordPress 7.1.2 ou versão estável posterior. Sites temporariamente presos a ramo antigo devem instalar o backport exato listado e planejar migração, pois o WordPress mantém ativamente apenas a linha mais recente. WAF é contenção complementar: não substitui a validação de caminhos adicionada ao Core.

wp db export backup-pre-cve-2026-87902.sql
wp core update
wp core update-db
wp core version
wp core verify-checksums

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Teste front-end, páginas, templates, tema filho, editor, cache, REST API e tarefas agendadas. Procure nos logs valores de pagename com codificação repetida ou travessia, além de PHP recente, plugins e administradores desconhecidos, mu-plugins, cron e alterações no tema. Se uma requisição alcançou o caminho vulnerável, trate o site como potencialmente comprometido e preserve evidências.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

Nos WordPress sob gestão contratada, a WebinHost cria backup, aplica o Core corrigido, valida checksums e tema e procura indicadores em logs e arquivos. Imunify360 acrescenta WAF, defesa proativa e detecção de malware; CloudLinux/CageFS limita o processo PHP à conta. Essas camadas reduzem tentativas e movimento lateral, mas a correção definitiva é o WordPress atualizado.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Referências oficiais e técnicas

• WordPress Core — advisory GHSA-7hp8-65ch-5whp
• WordPress.org — WordPress 7.1.2 Security Release
• CVE.org — CVE-2026-87902
• Wordfence — análise técnica e recomendações

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.