O upgrade também precisa ser seguro: a janela temporária do WordPress

A CVE-2026-119977 permite explorar uma instalação temporária do WordPress criada durante determinadas atualizações, caso um atacante alcance seu instalador antes da limpeza.[5] A correção chegou ao WordPress 7.1.4 e a linhas suportadas anteriores, mas a primeira instalação do conserto ainda começa executando o atualizador antigo.[5] É um exemplo de por que validar apenas o estado final deixa parte do risco sem resposta.

O que muda para quem desenvolve

O atualizador descompacta arquivos em wp-content/upgrade, onde a cópia pode formar uma instalação acessível pela web.[5] Em versões a partir de 5.9, o código antigo pode produzir um diretório previsível pelo nome do pacote; a proteção com nomes aleatórios só passa a valer plenamente em atualizações posteriores.[5] Portanto, versão de destino e segurança da transição são perguntas diferentes.

A correção que impede substituir o wp-config.php real já atua durante essa instalação, mas não elimina sozinha a execução do instalador temporário.[5] Minha leitura é que a atualização tem mais de uma propriedade de segurança, e confirmar uma delas não permite presumir as demais.

Como aplicar

A recomendação descrita na matéria é bloquear acesso web ao diretório de atualização antes do upgrade e confirmar resposta 403.[5] O bloqueio deve ficar na configuração do servidor ou em regra adequada no .htaccess da raiz, pois o atualizador antigo apaga o conteúdo do diretório temporário.[5]

Transforme isso em um procedimento com evidências: backup restaurável, bloqueio aplicado, resposta HTTP observada, atualização concluída e aplicação funcional. Verifique tanto o caminho público quanto o funcionamento do atualizador pelo sistema de arquivos. O bloqueio precisa impedir visitantes, não o processo legítimo de manutenção.

Para ensaiar, use uma cópia isolada do site e requisições inofensivas ao diretório protegido. Não exponha um instalador vulnerável para provar a necessidade da proteção. O critério é demonstrar a negativa de acesso na camada web antes de iniciar a mudança.

Cuidados e limites

A falha já consta do catálogo de exploração conhecida da CISA.[5] A reportagem também registra divergência de classificação entre o CVSS 8.1 atribuído pela Wordfence e a classificação baixa do aviso do WordPress.[5] Prefira decidir pela condição concreta de exposição, não pelo adjetivo de uma única fonte.

Pacotes parciais não são automaticamente seguros: o risco depende dos arquivos presentes e do atualizador instalado.[5] Depois da manutenção, investigue arquivos inesperados, administradores desconhecidos e acessos ao PHP temporário. Uma atualização bem-sucedida não responde, por si só, se alguém aproveitou a janela anterior.

Fonte

[5] Fonte: The Hacker News