WordPress: falha explorada na hora da atualização

O WordPress corrigiu em 28/10/2026 uma falha que transforma a própria atualização do site em porta de entrada. Identificada como CVE-2026-119977, ela afeta as versões 4.7 a 7.1.3 e, em 03/11, entrou no catálogo de vulnerabilidades exploradas da CISA, a agência de segurança cibernética dos Estados Unidos. Este texto resume o que se sabe e explica como atualizar sem abrir a janela para o ataque.

Se você tem um site em WordPress: veja como trabalhamos a segurança de sites, com revisão de atualizações, plugins e proteção do servidor.

O que é a falha

Durante uma atualização completa do núcleo, o WordPress descompacta a nova versão, com o instalador, numa pasta temporária dentro de wp-content/upgrade. Em muitos servidores essa pasta pode ser acessada pela web e tem nome previsível. Um atacante sem conta no site que chame o instalador no momento exato pode avançar até a execução de código PHP no servidor, segundo a Wordfence, empresa de segurança especializada em WordPress, citada pelo The Hacker News.

A janela costuma durar segundos, mas isso não protege o site. A falha está na lista de correções da versão 7.1.4 como "uma fraqueza no processo de atualização do WordPress que pode levar a execução remota de código durante a janela de atualização", ao lado de várias correções de XSS armazenado. O WordPress levou as correções de segurança para todos os ramos ainda elegíveis, até a 4.7.

Já há ataques

Segundo a Wordfence, foram quase 63 mil tentativas bloqueadas nas primeiras 24 horas depois da correção. Duas das maiores origens consultaram repetidamente pequenos grupos de sites por cerca de 14 horas e meia, comportamento de quem tenta acertar a janela curta da atualização. Em 03/11, a CISA confirmou a exploração ao incluir a falha no seu catálogo.

Para quem administra sites, a conclusão prática é que a atualização deixou de ser um momento neutro. Sites com atualização automática ligada recebem a correção pelo mesmo atualizador, e por isso o cuidado com a pasta temporária vale também para eles.

O alerta sobre a própria atualização

O pesquisador Umut Bayram, da Picus Security, que encontrou a falha, publicou um relato técnico com um alerta: a atualização que instala a correção ainda usa o código antigo, já presente no site, para descompactar os arquivos. Em sites a partir da versão 5.9, o nome da pasta temporária pode ser previsto uma última vez, durante essa atualização.

Segundo ele, nem toda atualização expõe o instalador. Pacotes completos sempre o incluem; pacotes parciais, feitos para uma versão específica de origem, só expõem o site se trouxerem esses arquivos. O The Hacker News conferiu que, de 7.1.3 para 7.1.4, o serviço do WordPress ofereceu pacote parcial, enquanto a mudança de um ramo mais antigo, como da 7.0.7, ofereceu só pacotes completos. Depois de instalada a 7.1.4 ou a correção do ramo, as atualizações seguintes usam pasta com nome aleatório.

Como atualizar com segurança

A primeira recomendação do pesquisador é impedir que o servidor web entregue a pasta wp-content/upgrade. O WordPress trabalha com ela direto no disco, então bloquear o acesso pela web não atrapalha as atualizações:

1. Nginx: uma regra location ^~ /wp-content/upgrade/ { deny all; }.
2. Apache: Require all denied num bloco <Directory> dessa pasta, na configuração do site.
3. Só com .htaccess: RedirectMatch 403 ^/wp-content/upgrade/ no arquivo da raiz do WordPress, acima das regras de reescrita.
4. Confirme que o endereço /wp-content/upgrade/ responde com erro 403.
5. Atualize para a 7.1.4 ou para a versão corrigida do seu ramo.

Não coloque um .htaccess dentro da própria pasta upgrade: o atualizador antigo apaga tudo nela antes de descompactar. A outra rota segura, segundo o pesquisador, é atualizar manualmente fora da pasta pública do site, com backup dos arquivos e do banco antes. O comando wp core update do WP-CLI não resolve, porque usa o mesmo atualizador e a mesma pasta.

Como saber se o site foi atacado

Procure nos registros do servidor requisições a arquivos PHP dentro de wp-content/upgrade e confira se surgiram administradores, plugins ou arquivos PHP que ninguém da equipe reconhece. Essas são as verificações citadas pela Wordfence para quem quer descartar uma invasão.

Se houver sinal de comprometimento, trate o site como invadido: restaure de um backup limpo, troque senhas, chaves e segredos do wp-config.php e revise o servidor. O guia meu site foi invadido: o que fazer traz o passo a passo, inclusive a avaliação de dados pessoais expostos, que pode exigir comunicação à ANPD.

O que fica de lição

Em poucas semanas, sites WordPress passaram por um plugin popular distribuído com malware (Rank Math PRO), uma falha crítica no PHP (PHP2Shell) e agora uma falha no próprio processo de atualização. O ponto em comum é que manter o site atualizado continua essencial, mas precisa ser feito com método: backup antes, servidor revisado e alguém acompanhando.

A Codlinx cuida da segurança de sites: revisão de versões de WordPress, PHP e plugins, proteção do servidor e recuperação de sites invadidos, com retorno em até 24 horas úteis, de segunda a sexta. Não temos plantão: em caso de invasão, conte o que aconteceu pelo formulário ou pelo WhatsApp.