Segurança no WordPress: falha expõe sites durante atualização

A segurança no WordPress enfrenta um paradoxo importante: o próprio processo de instalação de uma atualização pode abrir uma janela de oportunidade para invasores. Uma falha no mecanismo de atualização do núcleo, identificada como CVE-2026-119977, permite que um atacante remoto e não autenticado tente executar código no servidor enquanto determinados procedimentos de atualização estão em andamento.

Classificada com CVSS 8.1 (alta gravidade), a vulnerabilidade envolve uma condição de corrida (race condition) nos arquivos temporários utilizados pelo atualizador do WordPress. A situação merece atenção especial porque a CISA adicionou a falha ao catálogo Known Exploited Vulnerabilities (KEV) em 3 de novembro de 2026, confirmando a existência de exploração ativa. Vulnerability-Lookup+2

O risco exige uma mudança de procedimento: antes de iniciar uma atualização do WordPress, administradores devem restringir o acesso HTTP à pasta wp-content/upgrade. Essa precaução reduz a possibilidade de que alguém alcance os arquivos temporários do instalador durante a janela vulnerável, inclusive quando a atualização é executada automaticamente.

Como funciona a falha de segurança no WordPress e a condição de corrida

A origem do problema está na maneira como o WordPress Core prepara os arquivos necessários para substituir uma versão antiga do sistema. Durante uma atualização completa, o mecanismo de manutenção baixa um pacote compactado e utiliza a pasta wp-content/upgrade como área temporária de trabalho.

O procedimento normalmente segue estas etapas:

1. O WordPress baixa o pacote de atualização.
2. O arquivo é descompactado em um diretório temporário dentro de wp-content/upgrade.
3. O sistema verifica os arquivos conhecidos e prepara a substituição dos componentes antigos.
4. Os novos arquivos são copiados para a instalação principal.
5. O diretório temporário é removido.

O problema acontece entre a descompactação e a substituição dos arquivos. A cópia temporária contém componentes executáveis do WordPress, incluindo o instalador wp-admin/setup-config.php. Como o diretório está dentro da raiz pública do site em configurações convencionais, o servidor web pode permitir que visitantes acessem esses arquivos diretamente.

Essa situação caracteriza uma condição de corrida do tipo TOCTOU (Time-of-check to Time-of-use). O invasor precisa aproveitar o intervalo entre a preparação dos arquivos e sua utilização definitiva para interferir no processo de atualização.

A vulnerabilidade não representa uma porta de entrada permanentemente disponível. A exploração depende de uma atualização do núcleo em andamento, da exposição dos arquivos temporários e da capacidade de identificar o caminho utilizado pelo atualizador.

A exposição do instalador e a manipulação do wp-config.php

O componente mais preocupante nessa cadeia é o setup-config.php, responsável por conduzir a configuração inicial de uma instalação WordPress.

Durante a atualização, a cópia temporária pode interpretar que ainda não existe um arquivo de configuração válido. Isso acontece porque ela trabalha em uma estrutura de diretórios diferente daquela utilizada pela instalação original.

Um invasor que consiga acessar o instalador durante essa janela pode iniciar o procedimento de configuração e fornecer parâmetros de conexão para um banco de dados controlado por ele.

O processo permite criar um arquivo wp-config.php malicioso dentro da cópia temporária. O problema é que o mecanismo antigo de atualização pode posteriormente copiar esse arquivo para a instalação principal, substituindo a configuração legítima do site.

Com a configuração adulterada, o WordPress pode passar a utilizar um banco de dados controlado pelo invasor. Em determinadas condições, isso permite apresentar novamente a interface de instalação inicial e criar uma conta administrativa.

A partir dessa posição, o atacante pode instalar um plugin malicioso e executar código PHP arbitrário com as permissões do usuário utilizado pelo servidor web.

Isso significa que o comprometimento pode ultrapassar o painel administrativo e alcançar arquivos da instalação, dados acessíveis ao processo PHP e outros componentes do ambiente hospedado.

Quem está realmente em risco durante a migração

A falha afeta versões do WordPress a partir da linha 4.7 até a 7.1.3, incluindo diversas ramificações intermediárias. O risco, entretanto, depende do tipo de pacote utilizado e do comportamento do atualizador antigo.

Existem diferenças importantes entre pacotes completos e parciais:

• Pacotes completos: incluem uma distribuição abrangente do WordPress, com os arquivos do instalador. Consequentemente, apresentam condições mais favoráveis à exposição do componente temporário.
• Pacotes parciais: contêm somente os arquivos necessários para atualizar uma instalação específica. A exposição depende de o pacote incluir os componentes relevantes para a exploração.

Outro detalhe envolve a identificação do diretório temporário. Nas versões entre 4.4 e 5.8, o código antigo acrescenta caracteres aleatórios ao nome da pasta, dificultando sua descoberta. Isso não elimina a vulnerabilidade, pois o caminho pode ser revelado por outras formas, como mensagens de erro.

A partir da versão 5.9, o nome do diretório pode ser previsível porque deriva do nome do pacote baixado. Isso facilita a identificação do local utilizado durante a atualização.

O problema também alcança administradores que utilizam WP-CLI. O comando wp core update não elimina o risco, pois utiliza o mesmo mecanismo de atualização do núcleo e mantém a extração dos arquivos temporários dentro de wp-content/upgrade.

Portanto, trocar o painel administrativo pelo terminal não constitui uma medida de proteção suficiente.

Medidas obrigatórias de segurança no WordPress antes de atualizar

A principal recomendação é impedir que o servidor web entregue arquivos localizados em wp-content/upgrade.

Essa medida é especialmente importante porque o WordPress não precisa acessar essa pasta por HTTP para realizar a atualização. O mecanismo trabalha diretamente com os arquivos no disco, portanto, restringir o acesso externo não impede a extração nem a substituição dos componentes.

A regra deve ser aplicada antes de iniciar a atualização, inclusive quando o administrador pretende instalar uma versão que já contém a correção.

Isso ocorre porque o código antigo continua responsável por preparar os arquivos temporários durante a instalação do próprio patch. A correção só passa a proteger as próximas atualizações depois que a nova versão é instalada.

Configurando bloqueios no Nginx, Apache e .htaccess

Administradores devem escolher a configuração correspondente ao servidor web utilizado. Não é necessário aplicar simultaneamente todas as alternativas, embora seja possível implementar controles adicionais conforme a arquitetura.

1. Nginx

Abra o arquivo de configuração do servidor virtual responsável pelo site. Normalmente, ele está localizado em diretórios como /etc/nginx/sites-available/ ou /etc/nginx/conf.d/.

Dentro do bloco server, adicione:

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

A diretiva deny all impede que solicitações HTTP acessem o conteúdo desse diretório.

O modificador ^~ também evita que determinadas expressões regulares de outros blocos location sejam utilizadas para processar essas requisições.

Depois de salvar, valide a configuração:

sudo nginx -t

Se não houver erros, recarregue o serviço:

sudo systemctl reload nginx

2. Apache

No Apache, a recomendação é configurar a restrição diretamente no host virtual, utilizando o caminho absoluto da pasta de atualização.

Adicione ao bloco VirtualHost:

<Directory "/var/www/html/wp-content/upgrade">
    Require all denied
</Directory>

O caminho /var/www/html é apenas um exemplo. Substitua-o pelo diretório real da instalação WordPress.

A diretiva Require all denied impede que solicitações externas obtenham acesso aos arquivos protegidos.

Valide a configuração:

sudo apachectl configtest

Se o resultado indicar que a sintaxe está correta, recarregue o Apache:

sudo systemctl reload apache2

Em distribuições que utilizam o serviço httpd, como determinadas versões do RHEL, Rocky Linux e AlmaLinux, utilize:

sudo systemctl reload httpd

3. Utilizando .htaccess

Em hospedagens nas quais o administrador não possui acesso à configuração principal do servidor, é possível utilizar o arquivo .htaccess da raiz da instalação WordPress.

Adicione a seguinte regra antes das regras de reescrita do WordPress:

RedirectMatch 403 ^/wp-content/upgrade/

A instrução utiliza o módulo mod_alias do Apache para responder com HTTP 403 às solicitações direcionadas ao diretório protegido.

É importante que o servidor permita o uso de diretivas nesse contexto e que o módulo necessário esteja habilitado.

Atenção: não coloque o arquivo .htaccess dentro de wp-content/upgrade.

O atualizador antigo limpa o conteúdo dessa pasta antes de extrair os arquivos de uma atualização. Portanto, um arquivo de proteção colocado diretamente ali pode ser removido justamente quando sua presença seria necessária.

4. Testando o bloqueio

Depois de aplicar a configuração, faça uma solicitação HTTP ao diretório protegido:

curl -I https://seudominio.com/wp-content/upgrade/

O resultado esperado é:

HTTP/2 403

Uma resposta 403 confirma que o servidor está recusando a solicitação. Se o resultado for 200, o bloqueio não está funcionando como esperado e precisa ser revisado antes da atualização.

Lembre-se de que esse teste verifica o acesso ao diretório, mas não substitui a inspeção das configurações de acesso aos arquivos e subdiretórios.

Atualização manual fora da raiz web

Em ambientes corporativos, lojas virtuais e instalações que processam informações importantes, existe outra possibilidade: realizar uma atualização manual utilizando um diretório temporário localizado fora da raiz pública do servidor.

O procedimento reduz a exposição dos arquivos de instalação durante a preparação do novo núcleo.

O fluxo recomendado é:

1. Faça um backup completo dos arquivos do site e do banco de dados.
2. Baixe o pacote oficial da versão corrigida do WordPress.
3. Descompacte o arquivo em um diretório fora do document root, ou seja, em um local que não possa ser acessado diretamente pela internet.
4. Prepare a substituição dos arquivos do núcleo, preservando o wp-config.php original e todo o conteúdo de wp-content.
5. Copie os arquivos atualizados para a instalação, respeitando as permissões e a propriedade dos arquivos.
6. Acesse o painel administrativo e execute a atualização do banco de dados, caso seja solicitada.

O cuidado mais importante é não substituir inadvertidamente arquivos de configuração, uploads, plugins e temas personalizados.

Após a conclusão, verifique a versão instalada, teste as funcionalidades principais e confirme que o diretório temporário não contém arquivos inesperados.

Mesmo utilizando esse procedimento, mantenha o bloqueio HTTP de wp-content/upgrade como uma medida permanente de defesa.

Sinais de comprometimento e monitoramento pós-incidente

A existência de exploração ativa torna necessário verificar se alguma tentativa de ataque alcançou o ambiente. Administradores não devem presumir que a ausência de indisponibilidade significa que o site permanece íntegro.

A Wordfence recomenda observar indicadores relacionados ao acesso indevido aos arquivos temporários e à criação de componentes administrativos não autorizados.

Entre os principais sinais de comprometimento estão:

• Requisições inesperadas a arquivos PHP: acessos a arquivos como setup-config.php dentro de caminhos pertencentes a wp-content/upgrade.
• Contas administrativas desconhecidas: usuários com privilégios de administrador que não foram criados pela equipe responsável.
• Plugins não autorizados: extensões instaladas sem aprovação ou que apresentam nomes, arquivos e comportamentos desconhecidos.
• Arquivos PHP inesperados: scripts encontrados dentro de diretórios temporários de atualização, especialmente quando não correspondem aos arquivos legítimos do pacote.
• Alterações no wp-config.php: mudanças inesperadas nas credenciais do banco de dados, no endereço do servidor ou em outras configurações importantes.

Uma primeira verificação pode ser realizada diretamente no sistema de arquivos:

find wp-content/upgrade -type f -name "*.php" -ls

O comando lista arquivos PHP encontrados na área temporária. A presença de arquivos não significa automaticamente uma invasão, pois é necessário considerar se existe alguma atualização em andamento.

Também é importante revisar os registros de acesso do servidor web. No Nginx, por exemplo, os registros normalmente ficam em:

/var/log/nginx/access.log
/var/log/nginx/error.log

No Apache, os caminhos mais comuns incluem:

/var/log/apache2/access.log
/var/log/apache2/error.log

Em sistemas que utilizam httpd, os registros podem estar em /var/log/httpd/.

Procure por solicitações direcionadas a wp-content/upgrade, principalmente quando acompanhadas de acessos a instaladores PHP durante janelas de atualização.

Se houver evidências de comprometimento, preserve os registros, faça uma cópia forense dos arquivos relevantes e investigue o ambiente antes de simplesmente remover os componentes suspeitos.

Também é recomendável redefinir credenciais administrativas, revisar as chaves de autenticação do WordPress, verificar as credenciais do banco de dados e examinar possíveis alterações em tarefas agendadas, plugins e temas.

Caso a configuração do wp-config.php tenha sido comprometida, a simples instalação de uma versão corrigida não garante a recuperação da integridade do site.

Conclusão e boas práticas de manutenção de servidores

A CVE-2026-119977 demonstra que até mesmo mecanismos criados para melhorar a segurança podem apresentar problemas quando dependem de código legado e arquivos temporários expostos publicamente.

O aspecto mais preocupante é que a instalação da própria correção pode representar uma última oportunidade de exploração. Isso acontece porque o atualizador precisa utilizar o código antigo para preparar os arquivos da nova versão.

Para administradores, a prioridade deve ser estabelecer uma sequência segura: bloquear o acesso HTTP a wp-content/upgrade, confirmar que a restrição está funcionando e somente então aplicar a atualização correspondente à versão instalada.

O WordPress 7.1.4 recebeu a correção, e os reparos também foram disponibilizados para as ramificações antigas elegíveis, incluindo versões até a linha 4.7. Entre as versões corrigidas estão 7.0.8, 6.9.11, 6.8.12 e 6.7.11, além das respectivas atualizações das demais ramificações afetadas.

É importante distinguir a pontuação CVSS 8.1 atribuída ao registro da vulnerabilidade da classificação de gravidade apresentada pelo próprio projeto WordPress em seu comunicado. Independentemente dessa diferença de avaliação, a inclusão no catálogo KEV da CISA torna a aplicação das medidas preventivas especialmente urgente.

Por fim, a segurança de servidores web depende de defesa em profundidade. Atualizações frequentes, permissões adequadas, restrições de acesso a diretórios temporários, backups testados e monitoramento contínuo devem fazer parte da rotina de manutenção.