Em 3 de novembro de 2026, a CISA, agência de cibersegurança dos Estados Unidos, incluiu a CVE-2026-119977 no seu catálogo de vulnerabilidades exploradas ativamente. A falha está no processo de atualização do core do WordPress e permite que um atacante sem login execute código no servidor enquanto a atualização acontece. A correção saiu em 28 de outubro, no WordPress 7.1.4. A inclusão no catálogo significa que a agência tem evidência de exploração real, e não apenas de uma prova de conceito.
A janela aberta pela própria atualização
Segundo o registro no NVD, a base pública de vulnerabilidades do governo americano, a falha afeta as versões 4.7 a 7.1.3. Quando o WordPress faz uma atualização com o pacote completo do core, ele prepara os arquivos novos em caminhos previsíveis e acessíveis pela web. Quem souber o caminho e acertar o momento consegue executar código antes que a atualização termine. É uma condição de corrida: o sistema confere o arquivo num instante e o usa no seguinte, e o ataque acontece entre os dois.
A nota da Wordfence, que fez o registro da CVE, é 8,1 de 10. A pontuação considera a complexidade do ataque alta, porque depende de acertar essa janela, mas não exige conta nem ação de ninguém no site.
O anúncio do 7.1.4 descreve o problema como "uma fraqueza no processo de atualização do WordPress que pode levar à execução remota de código durante a janela de atualização". A mesma versão corrigiu mais de dez outras falhas, a maioria de XSS armazenado acessível a usuários com papel de colaborador ou superior.
Quem precisa olhar
Qualquer WordPress auto-hospedado entre o 4.7 e o 7.1.3 está no escopo. O projeto levou as correções a todos os ramos que ainda recebem segurança, até o 4.7. A API de atualização do WordPress.org hoje oferece, além do 7.1.4, versões como 7.0.8, 6.9.11 e 6.8.12 para quem está em ramos antigos. O próprio anúncio lembra que só a versão mais recente tem suporte ativo; os ramos antigos recebem apenas essas correções de segurança.
O risco é maior onde há muitos sites com atualização manual e espaçada: agências com carteira de clientes, empresas com vários sites institucionais, instalações que ninguém revisa desde a entrega. Nesses casos a atualização do core tende a rodar tarde, e cada atualização feita a partir de uma versão vulnerável abre a janela descrita na CVE.
O que fazer agora
O prazo de 6 de novembro definido pela CISA obriga apenas órgãos federais americanos. Para os demais, a referência prática é a mesma: a falha já está sendo explorada, então a correção não deve esperar a próxima janela de manutenção.
- Confirmar a versão de cada instalação. Valem o 7.1.4 ou a versão corrigida do ramo em uso, conforme a lista da API do WordPress.org.
- Verificar se as atualizações automáticas em segundo plano estão ligadas. Elas aplicam versões de segurança sem intervenção, mas podem estar desligadas, por exemplo em sites publicados por Git ou em hospedagens que controlam a versão do core.
- Rever os sites que fizeram atualização do core enquanto estavam vulneráveis. A CISA marcou a entrada com exigência de triagem forense, o que, para os órgãos federais, significa investigar além de aplicar a correção. Para um site privado, minha leitura é que vale conferir arquivos PHP criados ou alterados perto da data da última atualização e acessos incomuns no mesmo período.
O que os avisos ainda não dizem
A CISA registra como "desconhecido" o uso da falha em campanhas de ransomware, e nenhum dos avisos públicos informa quantos sites foram atacados nem como o ataque foi observado.
Também não está claro se a própria atualização para o 7.1.4, executada a partir de uma versão vulnerável, abre a janela uma última vez. A descrição fala do código de atualização das versões afetadas, e é esse código que roda quando o site se atualiza. Até que o projeto esclareça, faz sentido atualizar primeiro os sites de maior exposição e acompanhar os registros durante e logo depois da atualização.
Se a sua empresa está avaliando algo parecido, me chama no LinkedIn ou no WhatsApp.
