Falha em atualização do WordPress abre brecha para ataque remoto

Segurança Digital

Atualização do WordPress pode expor sites temporariamente a ataques remotos; saiba como se proteger dessa vulnerabilidade.

Leia também: mSecure alerta hoje sobre ataque e pede troca urgente de senhas

Sites que rodam WordPress entre as versões 4.7 e 7.1.3 podem ficar temporariamente expostos à execução remota de código justamente enquanto instalam a correção para a falha crítica CVE-2026-119977, alerta o pesquisador Umut Bayram, da Picus Security. O problema afeta tanto atualizações automáticas quanto manuais e já é alvo de ataques observados em campo.

Como a correção da falha explorada no WordPress pode expor temporariamente os sites?

A correção passa a valer de forma completa só depois que a atualização termina, mas o pacote é desempacotado usando o código antigo e vulnerável, o que abre uma pequena janela de ataque durante o processo.

Durante uma atualização de núcleo que usa pacote completo, o WordPress copia os arquivos da nova versão para uma pasta temporária dentro de wp-content/upgrade. Essa cópia inclui o instalador do WordPress, acessível via web na maioria dos servidores.

Segundo a análise de Umut Bayram, o código que gerencia essa etapa ainda é o antigo, sem correção, quando a atualização começa. Em instalações a partir da versão 5.9, o nome dessa pasta temporária é baseado no nome do arquivo baixado, o que o torna previsível uma última vez, até que a nova versão esteja totalmente instalada.

Se um invasor sem conta no site conseguir descobrir o nome dessa pasta e acessar o instalador antes de o processo de atualização ser concluído e a pasta ser apagada, ele pode configurar uma instância temporária de WordPress e executar código PHP com as mesmas permissões do servidor. “Um invasor que captura a janela durante a atualização pode configurar o instalador temporário com seu próprio banco de dados e executar código PHP com permissões do servidor”, explica Bayram.

O pacote de correção, lançado na versão 7.1.4 e em atualizações correspondentes para ramos anteriores, passa a dar um nome aleatório à pasta temporária e impede que um arquivo wp-config.php malicioso criado ali sobrescreva o arquivo real do site. Porém, essa proteção só é aplicada integralmente depois que os novos arquivos entram em produção; até lá, o passo de desempacotar ainda segue a lógica antiga.

Quais riscos os sites enfrentam ao instalar o patch para a vulnerabilidade do WordPress?

O principal risco é a execução remota de código durante a atualização, o que pode levar ao controle total do ambiente WordPress, ainda que por poucos segundos, em servidores vulneráveis.

A falha, com pontuação 8,1 de 10 na escala CVSS, permite que o atacante use o instalador temporário para criar uma instalação paralela, apontando para um banco de dados sob seu controle. A partir dessa instância, é possível rodar código PHP com as permissões do servidor web e, assim, ler ou alterar arquivos do site “ao vivo”.

Antes da correção, o cenário era ainda pior: o invasor podia usar o instalador para gerar um novo wp-config.php dentro da cópia temporária, que depois acabava sobrescrevendo o arquivo real durante a conclusão da atualização, comprometendo de vez a instalação. Essa etapa foi bloqueada pela correção atual.

Nem toda atualização, porém, expõe o instalador. Pacotes completos de atualização sempre levam os arquivos do instalador e, portanto, criam a pasta temporária explorável. Já pacotes parciais, construídos especificamente para saltos curtos de versão, podem ou não incluir esses arquivos — se não incluírem, o instalador não chega a ficar acessível.

Entenda o contexto

A vulnerabilidade CVE-2026-119977 atinge o núcleo do WordPress da versão 4.7 até a 7.1.3 e está sob exploração ativa, a ponto de a Agência de Segurança Cibernética e Infraestrutura dos EUA (CISA) incluí-la no seu catálogo oficial de falhas exploradas. A Picus Security e a empresa de segurança WordPress Wordfence vêm monitorando o uso do bug por atacantes.

De acordo com a Wordfence, as tentativas de ataque começaram nove minutos após a liberação da correção e da regra de firewall para a falha, e se estenderam por cerca de 14,5 horas, com fontes checando grupos reduzidos de sites repetidas vezes. O padrão indica que os invasores tentam acertar o exato momento em que os sites estão atualizando, quando a pasta temporária ainda existe.

A pesquisa também indica que a lógica vulnerável de atualização está presente no WordPress desde versões bastante antigas, e que instalações que permaneceram em versões sem suporte não recebem correções para o problema.

Existe uma forma segura de aplicar a correção para a falha sem expor o site temporariamente?

Sim. A recomendação número um é bloquear o acesso web à pasta wp-content/upgrade antes de atualizar, o que elimina a superfície exposta sem prejudicar o processo de atualização.

“WordPress trabalha diretamente com a pasta no disco, então bloquear o acesso web não quebra as atualizações”, afirma Umut Bayram. Isso pode ser feito, por exemplo, com regras de servidor web (como arquivos de configuração do Apache ou Nginx) que barrem qualquer pedido HTTP a esse caminho.

Outra alternativa defendida pelo pesquisador é abandonar temporariamente o fluxo padrão de atualização via web e fazer uma atualização manual fora da raiz servida pelo servidor. O procedimento sugerido é: fazer backup completo de arquivos e banco de dados, desempacotar a nova versão em uma pasta que não seja acessível pela web, copiar apenas os arquivos de núcleo por cima da instalação existente — sem tocar em wp-content nem em wp-config.php — e, em seguida, rodar a atualização de banco de dados do WordPress. Dessa forma, nenhum instalador temporário fica disponível em um caminho público.

Ferramentas de linha de comando como o WP-CLI não contornam o problema por padrão, já que usam a mesma rotina interna de atualização e também criam a pasta temporária em wp-content/upgrade.

Para instalações muito antigas, anteriores à versão 4.7 e já fora de suporte, não há patch específico: a orientação de especialistas é migrar o quanto antes para uma versão suportada, realizando a atualização em ambiente isolado e seguindo as mesmas práticas de bloquear o acesso à pasta de upgrade.

A combinação de aplicação rápida do patch, bloqueio de acesso à pasta temporária e monitoramento de arquivos e acessos anômalos reduz significativamente o risco de exploração dessa janela durante futuras atualizações.