A CISA, agência de cibersegurança dos Estados Unidos, incluiu em 3 de novembro de 2026 a CVE-2026-119977 no seu catálogo de vulnerabilidades exploradas. A falha no atualizador do WordPress permite executar código no servidor sem uma conta no site, durante a preparação de uma atualização completa do núcleo do CMS.
A correção saiu em 28 de outubro, no WordPress 7.1.4, e também foi distribuída para séries anteriores. Para quem administra blogs, lojas ou sites institucionais, a prioridade é conferir a versão efetivamente instalada e aplicar a correção correspondente à sua série.
A falha no atualizador do WordPress aparece durante a troca de arquivos
Durante uma atualização completa, o WordPress prepara os arquivos da nova versão em uma área temporária antes de concluir a instalação. O problema está em caminhos de preparação previsíveis e acessíveis pela web, que podem expor um instalador nesse intervalo. Um atacante que alcance essa etapa pode conseguir executar código antes de a atualização terminar.
O comunicado do WordPress 7.1.4, publicado em 28 de outubro, descreve a possibilidade de execução remota durante a janela de atualização e credita a descoberta a Umut Bayram, da Picus Security. Trata-se de uma vulnerabilidade do núcleo do WordPress, e não de uma extensão que o administrador poderia simplesmente desativar.
A CVE-2026-119977 é distinta das falhas de PHP abordadas no especial do Ponto Nulo sobre a onda de vulnerabilidades. Corrigir o interpretador PHP da hospedagem não aplica a correção ao atualizador do CMS: são componentes e atualizações diferentes.
A classificação técnica é uma condição de corrida do tipo TOCTOU, abreviação de time-of-check to time-of-use. Nessa classe de falha, a segurança depende do que acontece entre a verificação de um recurso e seu uso. Neste caso, o intervalo relevante é a preparação da atualização: o invasor precisa atingir uma etapa transitória, não apenas visitar uma página comum do site a qualquer momento.
A ficha técnica da Wordfence atribui CVSS 8,1, severidade alta, com exploração pela rede, sem privilégios e sem interação de outro usuário, mas com complexidade alta. A exigência de acertar essa janela limita a execução do ataque; não elimina o risco, agora confirmado pelo registro da CISA.
Quais versões receberam correção
A Wordfence identifica versões vulneráveis em várias séries, desde a 4.7. Por isso, comparar apenas o número principal com 7.1.4 produz uma conclusão errada: há versões corrigidas em séries anteriores, e o número completo da instalação precisa ser conferido.
| Série instalada | Versão com a correção |
|---|---|
| 7.1 | 7.1.4 |
| 7.0 | 7.0.8 |
| 6.9 | 6.9.11 |
| 6.8 | 6.8.12 |
| 6.7 | 6.7.11 |
| 6.6 | 6.6.11 |
A tabela é um recorte das séries recentes. A lista oficial de versões do WordPress permite conferir os pacotes publicados para as demais séries; a ficha da Wordfence relaciona as versões afetadas e corrigidas por ramo. Um site em 7.0.8, por exemplo, já contém essa correção, enquanto um em 7.1.3 ainda não.
O projeto esclarece no anúncio que somente a versão mais recente do WordPress tem suporte ativo. A disponibilização de uma correção para um ramo antigo não transforma esse ramo em alternativa permanente à manutenção e à migração da aplicação.
O que a confirmação de exploração muda
O catálogo Known Exploited Vulnerabilities, ou KEV, reúne falhas cuja exploração real é reconhecida pela CISA. O registro da CVE-2026-119977 não identifica os responsáveis pelos ataques, não quantifica sites comprometidos e marca como desconhecido o uso em campanhas de ransomware.
A agência fixou 6 de novembro como prazo de correção e exige triagem forense para as agências federais civis dos Estados Unidos abrangidas pela determinação. Esse prazo não é uma obrigação imposta pela CISA a todos os sites brasileiros.
Atualizar e investigar cumprem papéis diferentes
A documentação de segurança do WordPress recomenda manter o software atualizado, usar distribuições oficiais e preservar backups e registros de atividade. Para este caso, a primeira conferência é o número completo do núcleo em cada instalação, inclusive nas que são administradas por uma hospedagem ou por uma ferramenta de gestão de vários sites.
O fato de a falha ocorrer durante uma atualização não é motivo para deixar o site sem a correção. Em instalações antigas ou com atualização personalizada, o responsável técnico e a hospedagem precisam coordenar a aplicação do pacote oficial e o tratamento da área temporária conforme a configuração do servidor. Uma regra de bloqueio copiada sem avaliar o ambiente pode interferir no próprio processo de manutenção.
Depois da operação, é necessário confirmar a versão que ficou instalada. Ter iniciado uma atualização ou recebido um aviso de disponibilidade não comprova que ela terminou. A mesma distinção vale para atualizações automáticas: sua habilitação não substitui a conferência do resultado em cada site.
Quando houver arquivos inesperados, usuários administrativos desconhecidos ou alterações não autorizadas, o trabalho passa a incluir resposta a incidente. O guia oficial para sites comprometidos orienta documentar sintomas e horários, envolver a hospedagem, preservar uma cópia do ambiente antes da limpeza e revisar os acessos. Atualizar o núcleo fecha a vulnerabilidade corrigida, mas não remove automaticamente arquivos ou contas que um invasor já tenha criado.
