Uma vulnerabilidade no núcleo do WordPress está sendo explorada por cibercriminosos em ataques que podem permitir a execução remota de código nos servidores, sem exigir autenticação prévia. O problema, identificado como CVE-2026-119977, recebeu classificação de alta gravidade e chamou a atenção da Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA), que confirmou a exploração ativa e adicionou a falha ao catálogo de Vulnerabilidades Conhecidas e Exploradas (KEV).
O alerta é especialmente preocupante porque o ataque aproveita uma janela extremamente curta durante as atualizações completas do sistema. Nesse intervalo, caminhos temporários utilizados pelo processo de instalação podem ficar acessíveis pela internet, criando uma oportunidade para invasores tentarem executar comandos no servidor. A Wordfence já registrou mais de 18.500 requisições direcionadas aos arquivos envolvidos na exploração durante as primeiras 21 horas após a divulgação pública.
A situação exige atenção de administradores Linux, desenvolvedores e responsáveis por infraestrutura web. Como o problema está no próprio WordPress Core, não basta atualizar plugins ou trocar senhas administrativas. É necessário verificar a versão instalada, aplicar a atualização de segurança correspondente e investigar possíveis tentativas de exploração nos registros do servidor.
Como funciona a vulnerabilidade no núcleo do WordPress e o ataque TOCTOU
A CVE-2026-119977 é classificada como uma vulnerabilidade de condição de corrida do tipo TOCTOU (Time-of-check Time-of-use), registrada sob a categoria CWE-367. O problema recebeu pontuação 8,1 no CVSS 3.1, enquadrando-se como uma falha de alta gravidade.
O conceito TOCTOU descreve uma situação na qual existe um intervalo entre o momento em que um sistema verifica determinada condição e aquele em que efetivamente utiliza o recurso verificado.
Em aplicações vulneráveis, um invasor pode aproveitar essa diferença temporal para alterar arquivos, caminhos ou condições de execução depois da verificação inicial, mas antes da utilização efetiva do recurso.
No caso do WordPress, o problema está relacionado ao mecanismo responsável pelas atualizações do núcleo da plataforma. Durante uma atualização completa, o sistema prepara arquivos em diretórios temporários antes de substituir os componentes existentes.
É justamente nesse procedimento que surge a oportunidade de exploração.
A brecha durante a janela de atualização do core
Durante o processo de atualização, o WordPress utiliza arquivos e diretórios temporários para preparar os novos componentes do sistema. Alguns desses caminhos podem ser previsíveis e acessíveis por meio de requisições HTTP.
Entre os arquivos envolvidos está o setup-config.php, normalmente associado ao assistente de instalação inicial do WordPress.
O problema ocorre quando arquivos temporários relacionados ao processo de atualização ficam disponíveis em caminhos que podem ser identificados externamente. Um invasor pode monitorar esses locais e enviar requisições repetidamente na tentativa de alcançar o arquivo durante o curto período em que ele está presente e pode ser executado.
Essa condição transforma uma operação administrativa legítima em uma possível oportunidade de ataque.
A exploração depende de uma combinação de fatores, incluindo a execução de uma atualização completa, a disponibilidade dos caminhos temporários pela internet e a capacidade do invasor de acertar a janela de tempo.
Portanto, não significa que qualquer requisição enviada ao arquivo produzirá automaticamente uma invasão. O diferencial está na possibilidade de vencer a condição de corrida enquanto o procedimento de atualização está em andamento.
Ausência de autenticação prévia aumenta o risco
Um dos aspectos mais preocupantes da CVE-2026-119977 é que o invasor não precisa possuir uma conta no WordPress, nem privilégios administrativos ou acesso prévio ao painel.
O vetor de ataque utiliza requisições pela rede e não exige interação de um usuário legítimo.
Isso amplia o conjunto de possíveis alvos, principalmente porque o WordPress é utilizado em sites institucionais, lojas virtuais, portais de notícias e aplicações corporativas expostas publicamente.
A pontuação CVSS 3.1 de 8,1 considera a necessidade de alta complexidade para a exploração. Essa característica está relacionada justamente à janela temporal limitada e às condições necessárias para aproveitar a falha.
Caso consiga executar código arbitrário, o invasor poderá comprometer a integridade e a confidencialidade dos dados, além de afetar a disponibilidade do servidor. Dependendo das permissões concedidas ao processo PHP, o comprometimento também poderá abrir caminho para a instalação de backdoors, alteração de arquivos e acesso a informações armazenadas na infraestrutura.
Escala dos ataques e a determinação oficial da CISA
A movimentação dos criminosos começou rapidamente após a divulgação da vulnerabilidade. A telemetria da Wordfence, empresa especializada em segurança para WordPress, identificou um volume expressivo de requisições tentando alcançar os caminhos temporários utilizados pelo instalador.
Durante as primeiras 21 horas após a divulgação pública, foram registradas mais de 18.500 requisições direcionadas a caminhos de setup-config.php em diretórios temporários.
Em uma atualização posterior de seu registro de ameaças, a Wordfence informou ter bloqueado 13.703 ataques direcionados à vulnerabilidade nas 24 horas anteriores.
Esses números demonstram a velocidade com que operadores maliciosos começaram a procurar instalações potencialmente vulneráveis. Entretanto, é importante diferenciar tentativas de exploração de invasões confirmadas: a quantidade de requisições não representa o número de sites efetivamente comprometidos.
A Previdian também identificou atividade suspeita em seus sensores de honeypot. Foram registrados três eventos de exploração em 30 de outubro de 2026, associados a um endereço IP geolocalizado no Reino Unido.
Embora o volume observado pela Previdian seja menor, os registros independentes reforçam que a falha entrou no radar de operadores maliciosos.
O catálogo KEV e o prazo determinado pela CISA
Em 3 de novembro de 2026, a CISA adicionou oficialmente a CVE-2026-119977 ao seu catálogo Known Exploited Vulnerabilities (KEV).
Esse catálogo reúne vulnerabilidades para as quais existem evidências de exploração no mundo real. Portanto, a inclusão representa um sinal importante de que o problema deixou de ser apenas uma possibilidade teórica e passou a integrar o cenário de ameaças ativas.
A determinação também estabelece obrigações para as agências do Poder Executivo Federal Civil dos Estados Unidos (FCEB), que receberam prazo até 6 de novembro de 2026 para implementar as correções conforme as diretrizes aplicáveis.
Embora esse prazo não represente uma obrigação legal universal para todos os administradores de sites, ele funciona como um indicador importante da urgência atribuída pela agência à vulnerabilidade.
Para empresas privadas, provedores de hospedagem e administradores independentes, a recomendação é igualmente clara: não adiar a instalação das atualizações de segurança.
Passos essenciais para proteger o WordPress e mitigar a vulnerabilidade
A principal medida de proteção contra a CVE-2026-119977 é instalar uma versão corrigida do WordPress. A atualização de segurança WordPress 7.1.4, disponibilizada em 28 de outubro de 2026, inclui a correção para o problema.
A correção também foi disponibilizada para versões anteriores, permitindo que instalações mantidas em diferentes ramificações recebam os ajustes necessários.
Entre as versões corrigidas estão:
- WordPress 7.1.4: corrige as versões 7.1.0 até 7.1.3.
- WordPress 7.0.8: corrige as versões 7.0.0 até 7.0.7.
- WordPress 6.9.11: corrige as versões 6.9.0 até 6.9.10.
- WordPress 6.8.12: corrige as versões 6.8.0 até 6.8.11.
- WordPress 6.7.11: corrige as versões 6.7.0 até 6.7.10.
Outras ramificações também receberam atualizações, incluindo versões antigas a partir da série 4.7. A recomendação é utilizar a versão corrigida mais recente disponível para a ramificação instalada, preferencialmente migrando para uma versão atual e suportada.
Administradores devem adotar as seguintes medidas:
1. Verifique imediatamente a versão instalada: acesse o painel administrativo do WordPress ou utilize o WP-CLI para identificar a versão do núcleo. Não considere uma instalação protegida apenas porque plugins e temas estão atualizados.
2. Faça backup antes da manutenção: preserve os arquivos do site e o banco de dados. Armazene uma cópia em ambiente separado para permitir a recuperação caso alguma etapa da atualização apresente problemas.
3. Instale a atualização de segurança: utilize o mecanismo oficial de atualização do WordPress ou os pacotes disponibilizados pelo projeto. Em ambientes corporativos, valide previamente a compatibilidade em uma instalação de testes.
4. Monitore os registros do servidor: investigue requisições suspeitas direcionadas a caminhos temporários contendo setup-config.php. Analise os registros do servidor web, PHP, proxy reverso e WAF, especialmente durante janelas de atualização.
5. Utilize um WAF: um firewall de aplicações web pode ajudar a identificar e bloquear requisições suspeitas direcionadas aos arquivos envolvidos na exploração. Entretanto, essa proteção deve ser considerada uma camada adicional, nunca um substituto para a atualização.
6. Revise possíveis sinais de comprometimento: procure arquivos PHP inesperados, alterações recentes em componentes do WordPress, contas administrativas desconhecidas, tarefas agendadas suspeitas e conexões externas não autorizadas. Se houver indícios de invasão, realize uma investigação antes de simplesmente reinstalar ou atualizar o sistema.
Também é importante revisar as permissões dos arquivos e diretórios, restringindo o acesso de escrita ao mínimo necessário. Em servidores Linux, executar o PHP com privilégios reduzidos ajuda a limitar o impacto de uma eventual execução de código malicioso.
A vulnerabilidade no núcleo do WordPress demonstra que até mesmo procedimentos rotineiros de manutenção podem introduzir riscos quando existem falhas na forma como arquivos temporários são disponibilizados e utilizados.
Com a exploração ativa confirmada pela CISA e milhares de requisições maliciosas identificadas pela Wordfence, administradores não devem esperar por novos incidentes para agir.
