Falha grave no WordPress: como atualizar pra 7.1.4

O WordPress lançou em 28/10/2026 a versão 7.1.4, uma atualização de segurança que corrige 22 falhas. A mais grave está no próprio processo de atualização do core: segundo a Wordfence, um atacante sem login pode executar código no servidor durante os segundos em que o WordPress desempacota uma atualização completa. A falha afeta da 4.7 até a 7.1.3, tem nota CVSS 8.1 e não recebeu CVE.

Já tem gente tentando explorar. Segundo o The Hacker News, a Wordfence bloqueou 62.969 ataques em 24 horas. Se você cuida de algum site WordPress, confira a versão hoje. Abaixo estão o passo a passo pra atualizar (painel, WP-CLI e Docker), um bloqueio temporário pra nginx e Apache e o que checar depois.

O que é a falha da janela de atualização

Numa atualização do core feita com o pacote completo, as versões afetadas desempacotam os arquivos novos numa pasta com nome previsível dentro de wp-content/upgrade. Essa cópia temporária inclui o instalador do WordPress. Como essa pasta é acessível pela web em muitos servidores, quem pedir o instalador no instante certo consegue interagir com a cópia temporária e chegar à execução de PHP no servidor.

A Wordfence lista as condições pro ataque funcionar:

• uma atualização com o pacote completo, que traz os arquivos do instalador;
• acesso público pela web, com PHP, à pasta temporária;
• um caminho de pasta previsível ou descoberto;
• tempo suficiente pra completar o ataque antes de o WordPress apagar os arquivos temporários.

Nos testes de laboratório da Wordfence, a pasta ficou disponível só por alguns segundos. Uma tentativa isolada dificilmente dá certo. O problema é que os atacantes estão automatizando: ficam repetindo requisições a caminhos como setup-config.php dentro da pasta de upgrade, esperando o site começar a atualizar. Duas das maiores origens passaram cerca de 14,5 horas martelando os mesmos poucos sites, e outras testaram várias combinações de nome de pasta e de versão.

A correção da 7.1.4, segundo a Wordfence, deixa o nome da pasta temporária aleatório, adiciona uma proteção de índice e impede que dados de configuração da cópia temporária sejam promovidos de forma insegura.

As outras 21 correções

A página do 7.1.4 no HelpHub lista as demais: vários XSS armazenados (marcação de blocos, bloco de Categorias, rótulos de paginação de comentários e de navegação de posts, atualização seletiva do Customizer, pedidos de remoção de dados pessoais, nomes de usuário forjados, blocos de Imagem e Playlist), problemas na Interactivity API (incluindo uma negação de serviço persistente), vazamento de alterações não publicadas do Customizer pra visitantes sem login, uma falha de permissão nas Notas e a atualização dos certificados raiz por causa da revogação da eMudhra. Boa parte exige uma conta de Colaborador, Autor ou Editor, o que reduz o risco, mas XSS armazenado ainda pode levar ao sequestro da conta de um admin que abre a página maliciosa.

Como saber se o seu site está afetado

Qualquer WordPress da 4.7 à 7.1.3 que ainda não recebeu o patch do seu ramo está vulnerável. O anúncio oficial informa que as correções foram levadas pra todos os ramos que ainda recebem segurança, até o 4.7. Você está seguro se estiver nestas versões (ou mais novas dentro do mesmo ramo):

• 7.x: 7.1.4 (versão atual) e 7.0.8
• 6.x: 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18
• 5.x: 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31
• 4.x: 4.9.35, 4.8.34, 4.7.39

Na prática: pegue o seu ramo (os dois primeiros números da versão, como 6.8) e confira se o terceiro número é igual ou maior que o da lista. Exemplo: um site na 6.8.11 está vulnerável; na 6.8.12, corrigido.

O WordPress 4.6 e anteriores não recebem mais correções: o caminho é migrar pra uma versão suportada. E lembre que só a versão mais recente (7.1) tem suporte ativo; os patches nos ramos antigos são uma cortesia.

Pra ver a versão, abra Painel → Atualizações ou rode na pasta do site:

wp core version

Se o site tem atualização automática em segundo plano, o próprio anúncio diz que ela começa sozinha. Mesmo assim, a Wordfence recomenda conferir em vez de supor que deu certo.

Passo a passo: como atualizar o WordPress

A janela de ataque é justamente a atualização. Se você consegue mexer no servidor web, uma boa ordem é aplicar primeiro o bloqueio temporário da seção seguinte e atualizar logo depois. Antes de tudo, faça backup do banco e dos arquivos. Se o seu backup nunca foi testado, vale ler como atualizar um sistema PHP com backup testado.

Pelo painel

1. Entre como administrador.
2. Vá em Painel → Atualizações.
3. Clique em Atualizar agora e espere a mensagem de sucesso.
4. Volte em Painel → Atualizações e confirme a versão nova.

Pelo WP-CLI

Rode na pasta do site, com o usuário dono dos arquivos (por exemplo, sudo -u www-data em vez de root):

# backup do banco antes
wp db export antes-do-update.sql

# atualiza pra última versão (7.1.4)
wp core update

# ou, se você precisa ficar no seu ramo, só a última correção dele (ex.: 6.8 → 6.8.12)
wp core update --minor

# atualiza o banco, se a versão pedir
wp core update-db

# confere se os arquivos do core batem com os oficiais
wp core verify-checksums

No Docker (imagem oficial wordpress)

A imagem oficial no Docker Hub já tem a tag 7.1.4, e as tags latest e 7.1 foram atualizadas em 28/10. Só que tem uma pegadinha: o core fica no volume montado em /var/www/html, e o script de entrada da imagem só copia os arquivos do WordPress quando não encontra uma instalação na pasta. Ou seja, num site que já existe, baixar a imagem nova e recriar o container não atualiza o core.

Atualize a imagem (vale pra instalações novas e pro PHP e o Apache da imagem):

docker pull wordpress:7.1.4
docker compose up -d

E atualize o core que está no volume, pelo painel ou com a imagem wordpress:cli. Troque meu-wp pelo nome do container do site e passe as mesmas variáveis WORDPRESS_DB_* que ele usa:

docker run --rm --user 33:33 -e HOME=/tmp \
  --volumes-from meu-wp \
  --network container:meu-wp \
  -e WORDPRESS_DB_HOST=db \
  -e WORDPRESS_DB_NAME=wordpress \
  -e WORDPRESS_DB_USER=wp \
  -e WORDPRESS_DB_PASSWORD=senha \
  wordpress:cli wp core update

O --user 33:33 vem da documentação da imagem: as variantes cli são baseadas em Alpine e rodam com UID 82, enquanto as imagens Debian (apache e fpm) usam UID 33. Se o seu site usa a variante fpm-alpine, o UID já é 82 e você pode tirar o --user. Se você cuida de vários containers e quer um painel pra isso, tem uma comparação de Portainer, Dockge, Komodo e Dockyard aqui no blog.

Não dá pra atualizar agora? Bloqueio temporário

Isto não substitui a atualização. É uma medida pra fechar a porta enquanto você não consegue aplicar o patch (ou pra fazer antes de atualizar). A ideia é simples: nada dentro de wp-content/upgrade precisa ser servido pela web. O WordPress lê e copia esses arquivos pelo sistema de arquivos, então o bloqueio não atrapalha a atualização.

nginx

Dentro do bloco server { } do site:

location ^~ /wp-content/upgrade/ {
    deny all;
}

O modificador ^~ importa: ele faz o nginx usar esse bloco e parar de procurar, então a regra vence o location ~ \.php$ que manda os PHP pro PHP-FPM. Depois teste e recarregue:

nginx -t && systemctl reload nginx

Apache

No .htaccess da raiz do site ou no VirtualHost (precisa do mod_alias, que costuma vir ativo):

RedirectMatch 403 ^/wp-content/upgrade/

Se o 403 aparecer onde não devia, o post sobre erro 403 no Apache ajuda a entender qual regra está barrando. Se o WordPress mora numa subpasta (ex.: /blog/), ajuste o caminho nas duas regras.

Teste o bloqueio

curl -sI https://SEU-SITE/wp-content/upgrade/x.php | head -n 1

A resposta tem que ser 403. Depois de atualizar, você pode tirar a regra ou deixá-la: não há nada nessa pasta que precise ser público.

O que checar depois de atualizar

Se o site ficou sem patch desde 28/10, procure sinais de que alguém ganhou a corrida, como orienta a Wordfence.

1. Requisições a PHP dentro de wp-content/upgrade

# nginx (o zgrep lê também os logs rotacionados .gz)
zgrep -E "wp-content/upgrade/.*\.php" /var/log/nginx/access.log*

# Apache
zgrep -E "wp-content/upgrade/.*\.php" /var/log/apache2/access.log*

Respostas 403 ou 404 indicam só tentativa. Uma resposta 200 pra um PHP nessa pasta é o sinal de alerta.

2. Administradores, plugins e arquivos que você não reconhece

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list
wp core verify-checksums
wp plugin verify-checksums --all
find wp-content/upgrade wp-content/uploads -name '*.php'

O verify-checksums compara os arquivos com os oficiais e avisa sobre arquivo alterado ou sobrando no core e nos plugins do diretório oficial (plugins pagos ou próprios não entram nessa conferência). A pasta uploads normalmente não tem PHP nenhum, então qualquer .php ali merece atenção.

3. Achou algo estranho?

Trate como invasão: tire o site do ar ou coloque em manutenção, guarde os logs, restaure um backup anterior ao problema, troque as senhas dos administradores e do banco e gere novas chaves de segurança (salts) no wp-config.php. Só desativar o plugin ou apagar o arquivo estranho pode deixar outra porta aberta. Se o servidor também roda outros sistemas em PHP, aproveite pra conferir o PHP em si: tem um passo a passo no post sobre o PHP2Shell na lista da CISA.

Perguntas frequentes

A atualização automática já resolve?

Na maioria dos sites, sim: o anúncio oficial diz que a atualização em segundo plano começa sozinha onde está ativa. Mas confira em Painel → Atualizações ou com wp core version. Hospedagens, configurações e plugins podem desligar as atualizações automáticas sem você perceber.

A falha tem CVE?

Não. Segundo o The Hacker News, a falha não tem identificador CVE. A Wordfence classifica com CVSS 8.1 (alta).

Meu site está numa versão antiga, tipo 6.4. Preciso ir pra 7.1?

Pra fechar essa falha, basta a correção do seu ramo (6.4.14, no exemplo). Mas só a 7.1 tem suporte ativo, então vale planejar a migração. Se estiver na 4.6 ou antes, não há correção: precisa atualizar.

O bloqueio de wp-content/upgrade quebra a atualização?

Não. O WordPress desempacota e copia os arquivos pelo sistema de arquivos do servidor; ninguém precisa acessar essa pasta pela web.

Resumo

• Falha no processo de atualização do WordPress 4.7 a 7.1.3 permite execução de código sem login durante a janela de atualização.
• Corrigida na 7.1.4 e nos patches de cada ramo (7.0.8, 6.9.11, 6.8.12... até 4.7.39), lançados em 28/10/2026.
• Ataques já estão acontecendo: 62.969 bloqueados em 24 horas, segundo a Wordfence.
• Atualize pelo painel ou WP-CLI; no Docker, atualize o core que está no volume.
• Se não der pra atualizar já, bloqueie o acesso web a /wp-content/upgrade/.
• Depois, revise logs, administradores, plugins e arquivos PHP soltos.

Fontes: anúncio do WordPress 7.1.4, HelpHub do 7.1.4, Wordfence, The Hacker News e Docker Hub.