Uma vulnerabilidade no WordPress permite que um invasor assuma o site sem login ou senha. Além disso, ela já está sendo usada em ataques reais.


Em 3 de novembro de 2026, a CISA incluiu a falha CVE-2026-119977 no seu catálogo de vulnerabilidades exploradas. A CISA é a agência de cibersegurança do governo dos Estados Unidos. Enquanto isso, a Wordfence, especializada em segurança de WordPress, passou a bloquear milhares de tentativas de ataque por dia. O caso foi noticiado pelo BleepingComputer em 4 de novembro.


O WordPress ainda é a escolha de muitas agências e desenvolvedores para criar sites. Portanto, se o site da sua empresa foi feito nele, este alerta sobre a vulnerabilidade no WordPress é para você. A seguir, explicamos o que aconteceu, qual é o risco real e o que fazer agora.


O que aconteceu: a vulnerabilidade no WordPress em 5 pontos

  1. A falha está no núcleo do WordPress, e não em um plugin ou tema. Ou seja, atinge até sites sem nenhum complemento instalado.
  2. Ela pode levar à execução remota de código (RCE) sem autenticação. Na prática, um atacante pode chegar a rodar comandos no servidor sem ter conta no site.
  3. A correção já existe. O WordPress 7.1.4 saiu em 28 de outubro como atualização de segurança. Além disso, cada ramo antigo, até o 4.7, recebeu a sua própria versão corrigida.
  4. A CISA confirmou exploração ativa da vulnerabilidade no WordPress. Por isso, deu poucos dias de prazo para os órgãos federais americanos corrigirem seus sistemas. A agência também pediu que empresas privadas priorizem a atualização.
  5. As tentativas de ataque já estão em volume. Por exemplo, a Wordfence registrou de 13 mil a 20 mil tentativas bloqueadas por dia desde a divulgação. São tentativas barradas, e não invasões confirmadas.


Como funciona a falha CVE-2026-119977

Notebook com código em execução dentro de um data center, ilustrando a vulnerabilidade no WordPress durante a atualização


A vulnerabilidade no WordPress é do tipo TOCTOU (time-of-check time-of-use), uma condição de corrida que acontece durante a atualização do núcleo. Ela foi descoberta por Umut Bayram, pesquisador da Picus Security. Segundo a análise técnica publicada pela Picus, a exploração segue uma cadeia de etapas:

  1. A atualização abre uma pasta temporária. Durante uma atualização completa, o WordPress extrai a nova versão em um diretório previsível dentro de wp-content/upgrade/.
  2. O instalador fica exposto. Essa cópia temporária inclui o instalador setup-config.php. Como ele não enxerga a configuração do site em produção, entende que o WordPress ainda não foi instalado.
  3. O atacante cria uma configuração falsa. Pelo instalador, ele gera um arquivo wp-config.php que aponta para um banco de dados controlado por ele.
  4. A atualização faz o resto. Em seguida, o WordPress copia os arquivos temporários para a instalação principal. Assim, a configuração maliciosa sobrescreve a original.
  5. O site passa a usar o banco do invasor. Dessa forma, o atacante cria a primeira conta de administrador.
  6. Por fim, vem a execução de código. Em uma instalação comum, o administrador pode instalar plugins. Portanto, basta enviar um plugin malicioso para rodar código PHP no servidor.


Ou seja, não se trata de simplesmente trocar um arquivo. É uma cadeia que envolve o instalador temporário, a configuração do banco de dados e a própria atualização.


Por isso, a falha recebeu nota CVSS 8.1 (alta) da Wordfence. Ela não exige login nem interação do usuário e pode ser explorada pela internet. No entanto, a complexidade é alta, pois o atacante precisa acertar a janela de tempo da atualização.


Qual é o risco real para o site da sua empresa

Profissional de TI diante de alerta de acesso negado no data center, representando o risco de um site invadido pela vulnerabilidade no WordPress


Nem toda tentativa de exploração resulta em invasão. O ataque só funciona se o criminoso vencer a corrida durante uma atualização. Ainda assim, o volume de tentativas mostra que os criminosos já automatizaram o processo. Quando a exploração dá certo, um site tomado por uma vulnerabilidade no WordPress fica nas mãos do invasor. Consequentemente, isso abre caminho para:

  1. Instalação de webshells: uma porta dos fundos que dá controle do servidor ao atacante. Além disso, ela continua funcionando mesmo depois da atualização.
  2. Roubo de dados: o banco de dados guarda cadastros de clientes, formulários, pedidos e senhas de usuários.
  3. Uso do site contra seus clientes: por exemplo, páginas alteradas para distribuir malware ou capturar dados de pagamento.
  4. Danos à reputação e ao SEO: o Google e os navegadores marcam sites invadidos como perigosos. Como resultado, o tráfego despenca.


O histórico recente mostra que esse risco não é teórico. Em julho, outra vulnerabilidade no WordPress, a cadeia de falhas chamada wp2shell, ganhou exploits públicos. Logo depois, passou a ser usada para instalar webshells em servidores sem atualização. Em setembro, um grupo de hackers de língua chinesa usou a mesma cadeia para roubar mais de 18.500 registros. Por fim, se o site coleta dados pessoais, uma invasão pode exigir comunicação à ANPD e aos titulares, conforme a LGPD.


Quem está mais exposto

Em geral, os sites mais expostos à vulnerabilidade no WordPress são justamente os que ninguém acompanha:

  1. Sites entregues por agência e "esquecidos": o projeto acabou e não existe contrato de manutenção. Portanto, ninguém sabe quem atualiza.
  2. Landing pages de campanhas antigas e subdomínios criados para eventos ou testes.
  3. Sites que ainda não receberam a versão corrigida do seu ramo, muitas vezes porque a atualização automática foi desligada.
  4. Instalações anteriores à versão 4.7, que não receberam nenhuma correção para essa falha.


Além disso, o WordPress depende da versão do PHP do servidor. Em outubro, a falha no PHP batizada de PHP2Shell já havia colocado muitos sites em risco. Ou seja, quem não cuidou de uma atualização provavelmente está atrasado na outra também.


Atenção: a primeira atualização ainda é um momento de risco

Este é o detalhe que muita gente deixa passar. Segundo a análise da Picus, a atualização que instala a correção ainda é executada pelo código antigo do WordPress. Portanto, clicar em "Atualizar agora" em um site vulnerável deixa uma última janela de exploração aberta durante a própria atualização.


Depois que a correção está instalada, as atualizações seguintes já usam o mecanismo corrigido. Por isso, o pesquisador recomenda duas medidas para essa primeira atualização:

  1. Bloquear o acesso HTTP à pasta wp-content/upgrade/ no servidor web antes de atualizar. Em seguida, confirmar que o endereço retorna erro 403.
  2. Ou atualizar manualmente, extraindo os arquivos fora da pasta pública do servidor e copiando apenas os arquivos do núcleo.

Em sites críticos ou com muitos acessos, portanto, o ideal é fazer essa atualização com acompanhamento técnico.


O que fazer agora: 6 passos contra a vulnerabilidade no WordPress

Especialista em cibersegurança analisando vulnerabilidades no notebook, representando os passos para corrigir a vulnerabilidade no WordPress


  1. Confira a versão do WordPress. Ela aparece em Painel › Atualizações. Em seguida, compare com a versão corrigida do seu ramo, listada abaixo.
  2. Prepare a atualização. Primeiro, faça um backup completo de arquivos e banco de dados. Depois, bloqueie o acesso à pasta wp-content/upgrade/ ou planeje a atualização manual.
  3. Instale a versão corrigida do seu ramo, ou uma mais recente. Não é obrigatório pular direto para a 7.1.4. Por exemplo, as versões corrigidas são:
  4. Ramo 7.1: versão 7.1.4
  5. Ramo 7.0: versão 7.0.8
  6. Ramo 6.9: versão 6.9.11
  7. Ramo 6.8: versão 6.8.12
  8. Ramo 6.7: versão 6.7.11
  9. Ramo 6.6: versão 6.6.11
  10. Ramos anteriores, até o 4.7: a última versão de segurança de cada ramo
  11. Procure sinais de invasão. Por exemplo, administradores desconhecidos, plugins que ninguém instalou e um wp-config.php alterado. Além disso, verifique nos logs pedidos ao setup-config.php dentro de wp-content/upgrade/. Atualizar fecha a vulnerabilidade no WordPress, porém não remove um webshell já instalado.
  12. Troque as credenciais de administradores, do banco de dados e das chaves de API se houver qualquer suspeita.
  13. Coloque o site sob monitoramento. Um WAF no servidor bloqueia tentativas conhecidas. Além disso, um SOC com monitoramento 24/7 identifica comportamentos anormais antes que o invasor se instale.


A lição: site também é infraestrutura

Muitas empresas tratam o site apenas como peça de marketing. Foi entregue, está no ar, então está resolvido. No entanto, ele é um servidor exposto à internet 24 horas por dia. Além disso, roda um software que recebe correções críticas várias vezes por ano.

Em pouco mais de quatro meses, o núcleo do WordPress teve duas falhas graves exploradas em ataques. Desta vez, inclusive, o momento de risco foi a própria atualização. Por isso, atualizar "quando der" deixou de ser opção. Portanto, gestão de vulnerabilidades e testes periódicos de invasão precisam incluir o site, e não só a rede interna.



Perguntas frequentes sobre a vulnerabilidade no WordPress

O que é a CVE-2026-119977?

É uma vulnerabilidade no WordPress, presente no núcleo do sistema, que pode levar à execução de código no servidor sem login. Para isso, ela explora o instalador temporário durante a atualização. Além disso, a CISA confirmou que ela já é usada em ataques.


Qual versão do WordPress corrige a falha?

No ramo atual, a versão 7.1.4, lançada em 28 de outubro de 2026. Os ramos antigos, até o 4.7, receberam versões próprias, como 7.0.8, 6.9.11 e 6.8.12. Portanto, instale a versão corrigida do seu ramo ou uma mais recente.


Basta clicar em "Atualizar agora"?

Na primeira atualização, não é o ideal. Como ela ainda roda com o código antigo, existe uma última janela de risco. Por isso, bloqueie o acesso à pasta wp-content/upgrade/ antes ou faça a atualização manual.


Atualizar plugins e temas resolve?

Não. Como a falha está no núcleo, é preciso atualizar o próprio WordPress. Ainda assim, manter plugins e temas em dia continua importante.


Meu site foi feito por uma agência. Quem é responsável pela atualização?

Depende do contrato. Se não houver manutenção contratada, provavelmente ninguém está atualizando. Por isso, confirme com a agência ou com a sua equipe de TI ainda hoje.


Depois de atualizar, estou seguro?

Contra essa falha, sim. No entanto, o site pode ter sido invadido antes ou durante a atualização. Portanto, verifique se não há administradores, plugins ou webshells desconhecidos.


Conclusão: atualize com cuidado e confira quem cuida do seu site

A vulnerabilidade no WordPress apontada pela CISA tem correção disponível, mas o risco é alto para quem atrasar. Além disso, a própria atualização exige cuidado. Portanto, proteja a pasta de atualização, instale a versão corrigida e verifique sinais de invasão. Por fim, aproveite o alerta para responder a uma pergunta importante: quem é o responsável pela segurança do nosso site?

Não sabe se o site da sua empresa está exposto? Solicite à Bitsafe uma verificação de segurança do seu site WordPress.