Alguns sites com WordPress ainda podem ser alvo de ataques durante a instalação da correção de uma falha explorada ativamente, segundo Umut Bayram, pesquisador da Picus Security que identificou o problema.
A atualização que instala a correção ainda descompacta seus arquivos usando o código antigo e não corrigido do site. Por isso, um invasor que agir no momento certo pode executar código no servidor. O pesquisador recomenda bloquear o acesso web à pasta wp-content/upgrade do site antes de atualizar.
A falha, identificada como CVE-2026-119977 (sigla para Vulnerabilidades e Exposições Comuns), afeta as versões do WordPress da 4.7 até a 7.1.3. Durante uma atualização principal que usa um pacote completo, o WordPress descompacta uma cópia da nova versão em uma pasta temporária dentro de wp-content/upgrade. Essa cópia inclui o instalador do WordPress, que normalmente pode ser acessado pelo servidor web.
Um invasor sem conta que consiga descobrir o nome da pasta e acessar o instalador antes de o WordPress apagar a cópia pode acabar executando código no servidor. A Agência de Segurança Cibernética e de Infraestrutura dos EUA (CISA) incluiu a falha em seu catálogo de vulnerabilidades conhecidas e exploradas no início desta semana.
O WordPress lançou a correção na semana passada, na versão 7.1.4, e em atualizações equivalentes para as versões anteriores, até a 4.7, todas listadas em seu aviso de segurança.
A correção dá à pasta temporária um nome aleatório. Mas a atualização que instala a correção ainda descompacta seus arquivos usando o código antigo já presente no site, como mostra o código do atualizador do WordPress. Em sites com a versão 5.9 ou superior, esse código antigo nomeia a pasta com base no arquivo baixado, de modo que o nome ainda pode ser previsto nessa última vez.
Antes da correção, um invasor podia usar o instalador para gravar um novo arquivo de configuração, o wp-config.php, na cópia temporária. Em seguida, a atualização sobrescrevia o arquivo real do site com esse arquivo. A parte da correção que impede isso já funciona durante a atualização que a instala, porque o WordPress copia os arquivos para o lugar certo usando o código novo.
Um invasor que pegar a janela durante essa atualização ainda pode montar a cópia temporária do WordPress com seu próprio banco de dados, fazer login nela e executar código PHP (linguagem de programação usada em sites) com as permissões do servidor web antes de a cópia ser apagada, afirma Bayram em seu relatório técnico. A partir daí, o invasor pode ler ou gravar arquivos no site WordPress em funcionamento.
Quem Fica Exposto Durante a Atualização
Nem toda atualização expõe o instalador, afirma o pesquisador. Os pacotes completos sempre incluem os arquivos do instalador. Já um pacote parcial menor, criado para uma versão inicial específica, só expõe o site se, por acaso, contiver esses arquivos.
Em sites que permitem atualizações automáticas em segundo plano, o WordPress instala a correção automaticamente, pelo mesmo atualizador e pelas mesmas etapas.
O The Hacker News verificou hoje o serviço de atualizações do WordPress.org para várias versões. Em atualizações dentro de uma mesma versão principal, como da 7.1.3 para a 7.1.4, o serviço ofereceu um pacote parcial, inclusive para atualizações automáticas. Já na migração de uma versão anterior, como da 7.0.7 para a 7.1.4, ofereceu apenas pacotes completos.
Nas versões 4.4 até 5.8, o código antigo acrescenta caracteres aleatórios ao nome da pasta. Isso oculta o nome, a menos que o site o revele de outra forma, como em uma mensagem de erro, afirma o pesquisador.
Depois que a versão 7.1.4 ou a correção de uma versão equivalente é instalada, as atualizações seguintes usam um nome aleatório para a pasta, e um arquivo wp-config.php na cópia temporária nunca é copiado para substituir o real.
O Que Fazer Antes de Atualizar
A primeira recomendação do pesquisador é impedir que o servidor web sirva a pasta wp-content/upgrade. O WordPress trabalha diretamente com essa pasta no disco, então bloquear o acesso web não interrompe as atualizações, afirma.
- Bloqueie a pasta na configuração do servidor web. No Nginx, adicione location ^~ /wp-content/upgrade/ { deny all; }. No Apache, adicione Require all denied dentro de um bloco <Directory> para essa pasta na configuração do host virtual.
- Se você só puder editar o arquivo .htaccess, adicione RedirectMatch 403 ^/wp-content/upgrade/ ao arquivo .htaccess na raiz do WordPress, acima das regras de reescrita do WordPress.
- Não coloque um arquivo .htaccess dentro da própria wp-content/upgrade. O atualizador antigo apaga tudo nessa pasta antes de descompactar uma atualização, então o arquivo desapareceria justamente quando for necessário.
- Confirme que uma requisição para /wp-content/upgrade/ retorna um erro 403.
- Atualize para a versão 7.1.4 ou para a versão corrigida da sua versão principal.
A outra rota segura, segundo ele, é uma atualização manual feita fora da raiz web, ou seja, da pasta que o servidor web disponibiliza. Faça o backup dos arquivos e do banco de dados do site, descompacte a nova versão em uma pasta que o servidor web não sirva, copie os arquivos principais para o lugar certo sem tocar no wp-config.php ou em wp-content e, depois, execute a atualização do banco de dados do WordPress. Assim, nenhum instalador temporário é criado em uma pasta acessível pela web.
O comando wp core update da interface de linha de comando WP-CLI não é uma alternativa, porque usa o mesmo atualizador e descompacta o pacote na mesma pasta.
As versões 4.6 e anteriores do WordPress não recebem mais atualizações de segurança, por isso não há correção para elas. O pesquisador afirma que a falha também atinge o WordPress 2.7, lançado em 2008, e que esses sites devem migrar para uma versão com suporte.
Ataques e o Que Verificar
A inclusão da falha no catálogo da CISA nesta semana se baseou em evidências de exploração ativa, mas a agência não descreveu os ataques.
A Wordfence, empresa de segurança para WordPress que atribuiu o identificador CVE, registrou tentativas de ataque nove minutos depois de implantar uma regra de firewall para a falha, no dia do lançamento. Duas das fontes mais ativas passaram cerca de 14,5 horas verificando pequenos grupos de sites, o que, segundo a empresa em sua análise dos ataques, corresponde a tentativas de capturar o momento em que um site é atualizado.
A pontuação da falha no registro CVE é 8,1 em 10 na escala CVSS (Common Vulnerability Scoring System, ou Sistema de Pontuação de Vulnerabilidades Comuns). Em seus testes de laboratório, a janela durou apenas alguns segundos. O próprio aviso de segurança do WordPress classifica a falha como de baixa gravidade.
Códigos que seus autores descrevem como exploits para a falha aparecem em repositórios públicos do GitHub desde o início desta semana. Um deles afirma que seu código também funciona em sites que ainda usam uma pasta previsível durante atualizações com pacote completo. Não se confirmou se o código funciona de fato.
Para sites que continuaram em uma versão afetada após o lançamento, a Wordfence sugere procurar por:
- requisições inesperadas a arquivos PHP dentro de wp-content/upgrade
- contas de administrador que ninguém reconhece
- plugins que ninguém instalou
- arquivos PHP em wp-content/upgrade que ninguém colocou ali
Atualização
Em 6 de novembro, Bayram disse ao The Hacker News que a exposição de uma atualização parcial depende do conteúdo daquele pacote específico. Um pacote parcial contém apenas os arquivos que mudaram entre duas versões. Se eles não incluírem os arquivos do instalador, a cópia temporária não pode funcionar como uma instalação do WordPress, e o instalador nunca fica acessível.
Além disso, um site nem sempre recebe um pacote parcial quando ele existe. O WordPress recorre a um pacote completo se os arquivos principais do site não corresponderem às somas de verificação oficiais ou se a atualização for uma reinstalação.
O fator decisivo, afirmou o pesquisador, "não é parcial versus completo. É se o atualizador já instalado no site foi corrigido".
