CVE-2026-119977: falha no núcleo do WordPress já é explorada

O núcleo do WordPress tem uma falha de condição de corrida (CVE-2026-119977, CVSS 3.1 de 8.1) que permite execução remota de código sem autenticação durante o processo de atualização completa. A CISA adicionou a falha ao catálogo de vulnerabilidades exploradas (KEV) em 3 de novembro e exige correção em agências federais dos EUA até 6 de novembro. A Wordfence, que reportou o problema, registrou mais de 18.500 requisições contra o caminho do instalador exposto nas primeiras 21 horas após a divulgação pública.

Quem é afetado

A falha atinge o núcleo do WordPress nas versões 4.7.0 até 7.1.3 — praticamente qualquer instalação que não tenha aplicado a atualização de 28 de outubro. Não é uma falha de plugin ou tema: o problema está no próprio mecanismo de atualização do core, então todo site com atualizações automáticas desativadas ou atrasadas está na janela de risco.

A correção chegou na versão 7.1.4, com retroporte para os ramos ainda suportados: 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18 e versões equivalentes até o ramo 4.7.39. Sites em WordPress 4.6 ou anterior não recebem correção — essas versões já saíram de suporte e precisam migrar para um ramo mantido.

Por que a atualização automática não bastou para todo mundo

O problema é uma condição de corrida do tipo TOCTOU (verificação de tempo até uso, CWE-367). Ao rodar uma atualização completa do core, o WordPress descompacta os arquivos novos numa pasta de preparo com nome previsível dentro de wp-content/upgrade, e essa pasta inclui o instalador wp-admin/setup-config.php. Em muitos servidores essa pasta fica acessível via web e o PHP é executado nela — só que por poucos segundos, até o WordPress apagá-la.

Um atacante que acerta essa janela consegue acionar o instalador antes que a configuração do site exista, o que basta para rodar código PHP com o privilégio do servidor web. Antes da versão 7.1.4, a própria rotina de limpeza apagava o arquivo index.php da pasta de preparo — o arquivo que normalmente bloqueia a listagem de diretório —, então em servidores configurados para listar diretórios sem índice, o nome da pasta ficava exposto durante a limpeza. A versão 7.1.4 corrige os três pontos: acrescenta 16 caracteres aleatórios ao nome da pasta, recria o index.php em vez de apagá-lo, e para de copiar o wp-config.php para a pasta de trabalho.

Isso também explica por que plugin de firewall não é proteção suficiente aqui: o instalador roda fora do carregamento normal do WordPress, então um plugin de segurança que depende do bootstrap do core pode nunca ver a requisição.

O que fazer agora

1. Confirme a versão instalada em Painel → Atualizações, ou com wp core version via WP-CLI. Se não estiver em 7.1.4 (ou na versão mais recente do seu ramo), atualize imediatamente — a exploração já está em massa e automatizada.
2. Se as atualizações automáticas de manutenção e segurança estiverem desativadas (via wp-config.php ou plugin), reative-as ou aplique a atualização manualmente agora, sem esperar uma janela de manutenção.
3. Se o site ainda está em WordPress 4.6 ou anterior, não há correção disponível: planeje a migração para um ramo com suporte como prioridade, não como falha secundária.
4. Revise os logs de acesso do servidor por requisições a /wp-admin/setup-config.php ou a pastas com nome estranho dentro de wp-content/upgrade/ em torno da data da última atualização do core.
5. Se a atualização completa do core precisar ser feita manualmente num site público, desative a listagem de diretório no servidor web antes de começar e acompanhe os logs durante o processo — a exposição existe só enquanto a atualização está em andamento.

Perguntas frequentes

Preciso estar logado no WordPress para ser atacado?
Não. A falha é pré-autenticação — o atacante só precisa acertar o momento em que uma atualização completa do core está em andamento.

Meu plugin de segurança do WordPress me protege?
Não necessariamente. O instalador explorado roda fora do carregamento normal do WordPress, então um plugin de firewall que depende do core carregado pode não interceptar a requisição.

Atualizar para a versão mais recente já resolve?
Sim, desde que a versão final seja 7.1.4 (ou a correção equivalente do seu ramo). A atualização automática de segurança, ativada por padrão desde o WordPress 3.7, já cobre a maioria dos sites — o risco é maior em instalações que desativaram esse recurso.

A gravidade é realmente alta?
Aqui as fontes divergem: o próprio aviso do WordPress.org (GHSA-4w3m-c66w-69mg) classifica o problema como severidade baixa e não chega a atribuir um CVE. Já o NVD, a Wordfence (que reportou a falha) e a CISA tratam o caso como alto risco — CVSS 8.1 — e o incluíram no catálogo de exploração ativa. Na prática, o volume de ataques automatizados registrado pela Wordfence sustenta a leitura mais severa.

Conclusão

O WordPress move uma fração enorme dos sites em produção, e esta não é uma falha de plugin isolado: é o próprio mecanismo de atualização do core. Quem administra um site em WordPress — próprio ou de cliente — deve confirmar a versão hoje, não na próxima rodada de manutenção. O prazo federal dos EUA (6 de novembro) é só uma referência de urgência; a exploração ativa já está em curso desde a divulgação.