Seguir Uma vulnerabilidade de alta gravidade no WordPress Core está sendo ativamente visada em ataques, levando a Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) a adicionar a falha ao seu catálogo de Vulnerabilidades Conhecidas Exploradas (KEV). Rastreada como CVE-2026-119977, a vulnerabilidade possui uma pontuação CVSS de 8.1 e pode permitir que um invasor não autenticado execute código arbitrário em um servidor vulnerável durante uma atualização do WordPress Core.
A vulnerabilidade origina-se de uma condição de corrida de tempo de verificação e tempo de uso (TOCTOU) no processo de atualização do WordPress. Durante atualizações completos do Core, o WordPress temporariamente coloca arquivos de instalação em locais previsíveis e acessíveis na web. Os invasores podem sondar repetidamente esses locais e tentar alcançar componentes do instalador durante o curto período em que uma atualização está ocorrendo.
O WordPress resolveu a questão na versão 7.1.4, lançada em 28 de outubro de 2026. A vulnerabilidade afeta versões do WordPress de 4.7 até 7.1.3, enquanto correções de segurança também foram retrocompatíveis para branches mais antigas elegíveis. O WordPress enfatiza que apenas a versão mais recente é suportada ativamente.
O risco já não é mais apenas teórico. A telemetria do Wordfence citada pelo The Hacker News registrou mais de 18.500 solicitações direcionadas a caminhos de instalação setup-config.php em estágio durante as primeiras 21 horas após a divulgação. A CISA posteriormente confirmou evidências de exploração e exigiu que as agências civis federais aplicáveis dos EUA remediem a vulnerabilidade até 6 de novembro de 2026.
As equipes de segurança podem usar a Plataforma SOC Prime para fortalecer a cobertura de detecção contra técnicas emergentes de exploração e buscar atividade suspeita associada a sistemas vulneráveis voltados para a internet. Detecte a exploração da CVE-2026-119977 monitorando solicitações anormais para locais de atualização do WordPress, execução PHP inesperada, contas administrativas recém-criadas, arquivos suspeitos e comportamento pós-exploração.
O conteúdo de detecção pode não estar disponível para todos os CVEs. Verifique a Plataforma SOC Prime para cobertura atual. Se detecções relevantes ainda não estiverem disponíveis, verifique novamente, pois novas informações de ameaça e conteúdos de detecção são continuamente adicionados.
Análise do CVE-2026-119977
O CVE-2026-119977 é classificado como uma condição de corrida TOCTOU sob a especificação CWE-367 e tem uma pontuação CVSS 3.1 de 8.1. Seu vetor reflete uma exploração baseada em rede que não requer privilégios ou interação do usuário, com alto potencial de impacto na confidencialidade, integridade e disponibilidade. A complexidade do ataque é classificada como alta, pois uma exploração bem-sucedida depende de alcançar um recurso vulnerável durante uma breve janela de atualização.
O CVE-2026-119977 afeta versões do WordPress Core de 4.7 até 7.1.3. A fraqueza não está ligada a um plugin ou tema de terceiros; ela existe no próprio mecanismo de atualização do software Core.
A questão ocorre durante atualizações completas do Core. O WordPress extrai temporariamente o novo pacote em um local de estágio embaixo do diretório wp-content/upgrade antes de substituir a instalação existente. Nas versões afetadas, porções desse local de estágio podem ser previsíveis e acessíveis a partir da web enquanto a atualização está em andamento.
Um componente particularmente importante é o instalador setup-config.php em estágio. Um invasor não autenticado que preveja corretamente o caminho temporário e alcance esse componente antes que o WordPress complete a limpeza pode ser capaz de interagir com a instalação em estágio e, por fim, executar código PHP no servidor.
Isso cria um modelo incomum de exploração. Um site WordPress vulnerável não é necessariamente explorável de forma contínua. Em vez disso, o invasor deve capturar o site durante o breve período em que uma atualização completa expõe os arquivos de estágio. Pesquisadores indicam que a oportunidade pode durar apenas alguns segundos.
Os invasores podem compensar essa limitação através da automação. Ao invés de fazer uma única solicitação, os atores de ameaça podem sondar continuamente caminhos de atualização potenciais e esperar que um alvo comece a atualizar. O Wordfence observou atacantes solicitando repetidamente variações de locais de instaladores em estágio, demonstrando que atores do mundo real rapidamente entenderam como alvejar a condição de corrida.
O grande volume de solicitações observadas deve, no entanto, ser interpretado cuidadosamente. Os números relatados representam solicitações bloqueadas ou tentativas de exploração e não significam que cada solicitação resultou em execução remota de código bem-sucedida. A exploração ainda requer que a solicitação coincida com uma atualização completa ativa e outras condições de servidor necessárias.
A telemetria inicial do Wordfence mostrou mais de 18.500 solicitações contra caminhos de instaladores em estágio nas primeiras 21 horas. O GBHackers posteriormente relatou quase 59.000 tentativas bloqueadas dentro de um período de 24 horas, enquanto o The Hacker News citou telemetria adicional demonstrando atividade contínua de exploração.
A telemetria de honeypot independente citada pelo The Hacker News registrou tentativas de exploração em 30 de outubro, apoiando ainda mais a decisão do CISA de classificar a vulnerabilidade como ativamente explorada. A adição da falha ao KEV pela CISA aumenta significativamente a urgência para organizações que operam infraestrutura do WordPress pública.
No momento da escrita, as fontes revisadas não documentam um repositório publicamente validado e amplamente disponível de PoC para CVE-2026-119977. No entanto, código de exploração público não é necessário para estabelecer o risco, pois tentativas de exploração já foram observadas em larga escala e o CISA confirmou a exploração ativa.
O WordPress 7.1.4 altera o processo de atualização vulnerável. De acordo com os relatórios técnicos disponíveis, a remediação inclui tornar as localidades de estágio menos previsíveis, introduzir proteções adicionais contra acesso direto e prevenir que dados de configuração em estágio sejam promovidos de forma insegura.
O WordPress creditou o pesquisador de segurança Umut Bayram por relatar a fraqueza do processo de atualização. A versão 7.1.4 foi lançada em 28 de outubro de 2026, e o registro CVE foi posteriormente publicado em 31 de outubro.
Para detecção do CVE-2026-119977, os defensores devem prestar atenção especial a solicitações da web que almejam caminhos incomuns embaixo de wp-content/upgrade, especialmente solicitações que referenciam cópias em estágio de setup-config.php. Solicitações repetidas em múltiplos diretórios de estágio possíveis podem indicar sondagens automatizadas tentando vencer a condição de corrida.
A exploração bem-sucedida pode potencialmente proporcionar a execução remota de código PHP no contexto do servidor web afetado. Os defensores devem, portanto, correlacionar solicitações suspeitas de caminho de atualização com evidências subsequentes, como arquivos PHP inesperados, modificação de dados de configuração do WordPress, contas de administrador desconhecidas, plugins maliciosos, processos filhos incomuns gerados pelo servidor web, ou conexões de saída inesperadas.
Relatórios públicos não identificaram um conjunto abrangente de IOCs específicos do invasor para CVE-2026-119977, como domínios de comando e controle estáveis ou hashes de malware. Isso torna a detecção baseada em comportamento particularmente importante. Solicitações para caminhos de estágio previsíveis, atividade suspeita durante a janela de atualização e modificações pós-exploração oferecem oportunidades de caça mais duradouras do que depender exclusivamente de indicadores estáticos.
Mitigação do CVE-2026-119977
A principal mitigação para CVE-2026-119977 é atualizar o WordPress imediatamente. O WordPress 7.1.4 contém a correção de segurança, e correções também foram disponibilizadas ou retrocompatibilizadas para ramos de lançamento mais antigos e elegíveis. As organizações devem priorizar a migração para a versão mais recente do WordPress suportada ativamente em vez de confiar indefinidamente em retrocompatibilidades de segurança legadas.
Os administradores devem tomar as seguintes ações:
- Atualize instalações do WordPress voltadas para a internet para a versão 7.1.4 ou posterior.
- Verifique se as atualizações automáticas foram concluídas com sucesso em vez de assumir que uma atualização foi aplicada.
- Faça um inventário de instalações mais antigas do WordPress, incluindo sites de desenvolvimento, de estágio e legados esquecidos.
- Revise logs de servidores web e WAF para solicitações que visam wp-content/upgrade e caminhos setup-config.php em estágio.
- Investigue arquivos PHP inesperados, novas contas de administrador do WordPress, plugins não autorizados e alterações de configuração inexplicadas.
- Revise conexões de saída e processos filhos do servidor web em busca de evidências de atividade pós-exploração.
- Garanta que as proteções WAF operem cedo o suficiente no caminho da solicitação para cobrir solicitações diretas para arquivos PHP temporários.
- Considere restringir o acesso direto à web a diretórios de atualização temporários onde operacionalmente viável.
Regras de firewall de aplicação web podem reduzir a exposição a tentativas de exploração automatizadas, mas não devem ser tratadas como um substituto para a aplicação de patches. Como o recurso vulnerável pode existir temporariamente fora do fluxo normal de solicitações do WordPress, os administradores devem verificar se a implantação do WAF realmente inspeciona solicitações diretas para arquivos PHP em estágio.
As organizações que atualizaram enquanto a exploração ativa já estava em andamento também devem considerar uma investigação retrospectiva. Concluir a atualização remove o comportamento vulnerável, mas não prova que o servidor não foi comprometido enquanto o diretório de estágio vulnerável estava disponível.
Revise logs de acesso em torno do exato timestamp de atualização. Solicitações para os caminhos de estágio afetados que ocorrem imediatamente antes ou durante a atualização devem receber escrutínio adicional. As equipes de segurança devem então correlacionar essas solicitações com alterações no sistema de arquivos, modificações em contas do WordPress, execução de PHP, conexões de rede suspeitas e outros indicadores de pós-exploração.
Se houver suspeita de comprometimento, isole o host afetado onde prático, preserve logs relevantes de web, aplicação, autenticação e sistema, e colete arquivos suspeitos antes da remediação. Credenciais e segredos acessíveis ao processo WordPress/PHP devem ser considerados potencialmente expostos e rotacionados com base nos achados da investigação.
A inclusão da vulnerabilidade no KEV pela CISA confirma que a remediação deve ser tratada como uma prioridade operacional imediata em vez de um item de ciclo de patch rotineiro. Agências do Federal Civilian Executive Branch foram direcionadas a abordar a questão até 6 de novembro de 2026.
FAQ
O que é o CVE-2026-119977 e como ele funciona?
O CVE-2026-119977 é uma vulnerabilidade de execução remota de código não autenticada de alta severidade no WordPress Core causada por uma condição de corrida TOCTOU no processo de atualização. Durante atualizações completos do Core, o WordPress temporariamente coloca arquivos de instalação em locais previsíveis e acessíveis na web. Um atacante que alcança o instalador em estágio durante essa breve janela pode ser capaz de executar código PHP arbitrário no servidor.
Quando o CVE-2026-119977 foi descoberto pela primeira vez?
O WordPress creditou o pesquisador de segurança Umut Bayram por relatar a vulnerabilidade. O WordPress lançou a versão 7.1.4 contendo a correção em 28 de outubro de 2026, enquanto o registro CVE foi publicado em 31 de outubro. As fontes revisadas não especificam a data exata em que a vulnerabilidade foi originalmente reportada em privado ao WordPress.
Qual é o impacto do CVE-2026-119977 nos sistemas?
Uma exploração bem-sucedida pode permitir que um invasor remoto não autenticado execute código arbitrário no servidor WordPress afetado durante a janela de atualização vulnerável. Dependendo dos privilégios do processo do servidor web e das ações subsequentes do atacante, isso pode levar ao comprometimento do site, implantação de arquivos maliciosos, roubo de dados, persistência, exposição de credenciais ou invasão adicional em infraestrutura conectada.
O CVE-2026-119977 ainda pode me afetar em 2026?
Sim. Instalações do WordPress executando versões afetadas permanecem em risco e a exploração está ocorrendo na prática. A CISA adicionou a vulnerabilidade ao seu catálogo de Vulnerabilidades Conhecidas Exploradas após evidências de ataques ativos, enquanto fornecedores de segurança registraram dezenas de milhares de solicitações tentando alcançar caminhos de estágio vulneráveis.
Como posso me proteger do CVE-2026-119977?
Atualize o WordPress para a versão 7.1.4 ou um lançamento suportado posterior imediatamente e confirme que a atualização foi concluída com sucesso. Revise logs de servidores web e WAF para solicitações que visam diretórios de atualização temporários, inspecione sites para arquivos PHP não autorizados, contas de administrador, plugins ou alterações de configuração, e investigue sistemas que foram atualizados enquanto as tentativas de exploração estavam em andamento. As organizações devem também monitorar os avisos do WordPress e da CISA para obter detalhes atualizados sobre o CVE-2026-119977 à medida que o cenário de exploração se desenvolve.
