Em 22 de setembro de 2026, véspera do feriado do Dia Nacional, o WordPress lançou a atualização de segurança 7.1.2 para fechar a CVE-2026-87902. A falha não está em um plugin nem em um tema. Está no núcleo do WordPress e afeta todas as versões da 4.7.0 à 7.1.1. No mesmo dia, às 11:49 UTC (2:49 da tarde no horário de Riad), a empresa de segurança Patchstack viu a primeira tentativa de explorá-la e, menos de quatro horas depois, a primeira tentativa de gravar um arquivo no servidor de um site.

Como o ataque se espalhou em cinco dias

Depois, ele se espalhou. Segundo o relatório da CrowdSec publicado hoje, 28 de setembro, sua rede registrou 322.680 sinais de ataque correspondentes à falha vindos de 30.813 endereços IP distintos entre 23 e 27 de setembro, com pico em 27 de setembro, com 124.154 sinais. A Autoridade Nacional de Cibersegurança (NCA) da Arábia Saudita emitiu um alerta Crítico, nº 2026-7873, em 23 de setembro, e a agência americana CISA adicionou a falha ao seu catálogo de vulnerabilidades exploradas conhecidas em 25 de setembro.

O que a falha faz, em termos simples

Quando um visitante solicita uma página, o WordPress decide qual arquivo de modelo do tema usar para exibi-la. O bug está nessa etapa: um atacante que não está logado pode apontá-la para um arquivo PHP que está no servidor fora da pasta do tema, e o WordPress vai executá-lo. O WordPress classifica a falha com 9.2 de 10; a CISA, com 8.1.

Ela se transforma em controle do site quando as condições apontadas no comunicado do WordPress e nos relatórios dos pesquisadores se alinham:

  • O tema: o tema ativo contém uma pasta cujo nome começa com page-. O comunicado lista Twenty Twelve, Twenty Fourteen, Neve, Hestia e Sydney entre os temas que têm essa pasta.
  • Uma configuração do PHP: register_argc_argv está ativado, o que, segundo a CrowdSec, é o padrão nas imagens Docker oficiais do PHP e em servidores cPanel com PHP anterior à 8.5.
  • Um arquivo auxiliar: o pearcmd.php do PEAR está presente no servidor. Os atacantes o usam para gravar novos arquivos PHP, ou seja, uma porta dos fundos que sobrevive à atualização.

Então a falha não atinge todos os sites da mesma forma, mas a Security Affairs resume assim: a execução de código exige que a configuração do servidor se alinhe, e muitos servidores se alinham. O dono de uma empresa normalmente não sabe qual tema está ativo nem como o servidor está configurado, então a suposição segura é que o site está exposto até prova em contrário.

Por que o ataque veio em horas, e não em semanas

Uma atualização de segurança revela, por natureza, onde está o bug, porque a mudança no código é pública. A Patchstack diz que os primeiros payloads seguiam exatamente o padrão que a correção fechou, o que significa que quem os escreveu partiu da própria correção, e não de uma descoberta independente. As primeiras tentativas solicitavam arquivos comuns do núcleo do WordPress, como wp-login.php e wp-cron.php, para ver como os sites respondiam, e depois passaram a gravar arquivos.

O tráfego também traz as marcas de scanners automatizados e de código de prova de conceito publicado. Para o dono de uma empresa, isso significa que ninguém está escolhendo o seu site em particular. As ferramentas varrem todos os sites WordPress que conseguem alcançar, e a diferença entre um site comprometido e um limpo é se a atualização chegou antes delas.

Seu site se atualiza sozinho?

Provavelmente, mas não conte com isso. O WordPress tem atualizações automáticas em segundo plano desde a versão 3.7 e, desde a 5.6, as novas instalações atualizam automaticamente tanto as versões menores quanto as principais. O anúncio da 7.1.2 diz que os sites que suportam atualizações automáticas em segundo plano começarão a se atualizar automaticamente.

Mas as atualizações automáticas podem ser desativadas com uma única linha no wp-config.php. Alguns desenvolvedores as desativam de propósito para que uma atualização não quebre um tema personalizado, e algumas hospedagens gerenciam as atualizações por conta própria. Um site que um freelancer construiu anos atrás, cujo contrato já terminou, pode ficar em uma versão antiga sem que ninguém perceba. Para verificar:

  • Faça login no painel administrativo do site, abra a página Atualizações no menu Painel e você verá a versão atual ali.
  • A versão segura é a 7.1.2 ou posterior. Se o seu site estiver em um ramo mais antigo, a correção chegou a todos os ramos até a 4.7, incluindo 7.0.6, 6.9.9, 6.8.10 e 4.7.37; a lista completa está no comunicado do WordPress indicado nas fontes.
  • Observe que o WordPress diz que apenas a versão mais recente recebe suporte ativo. Um site deixado em um ramo antigo recebeu esta correção, mas está vivendo de tempo emprestado. Mostramos o que a nova versão traz para um site corporativo em WordPress 7.1: as principais novidades.

O Elementor também: um link basta

Na mesma semana, o Elementor, o popular construtor de páginas do WordPress, corrigiu uma falha apenas nas versões 4.3.0 e 4.3.1. Se um administrador do site abrir um link manipulado enquanto estiver logado, um atacante pode criar uma conta de administrador que ele controla, e o link pode chegar por e-mail, chat ou comentário. Segundo o BleepingComputer, essas versões rodam em até 2 milhões de sites. A correção saiu na 4.3.2 em 24 de setembro, e o site não relatou exploração ativa no momento da publicação.

Garanta que o Elementor esteja na 4.3.2 ou posterior e transforme isto em regra da equipe: não abrir links de mensagens ou comentários enquanto estiver logado no painel administrativo do site.

Se o seu site não foi atualizado desde 22 de setembro

  • Atualize agora: se o desenvolvedor teme que a atualização quebre algo, a Patchstack diz que o caminho pode ser fechado temporariamente bloqueando tentativas de travessia de diretórios no parâmetro pagename, ou desativando register_argc_argv. Isso é trabalho para a hospedagem ou o desenvolvedor, e não substitui a atualização.
  • Considere que seu site foi sondado: peça ao desenvolvedor ou à hospedagem que procure arquivos PHP que ninguém adicionou, especialmente em /tmp e /var/tmp, onde a Patchstack cita arquivos como poc87902.php e wp-pear-rce-flag.php como sinais de execução de código bem-sucedida.
  • Se algo aparecer: trate como um incidente, não como uma atualização. Troque as senhas das contas de administrador, do banco de dados e da hospedagem, restaure o site a partir de um backup limpo e depois atualize-o.
  • Se o site guarda dados de clientes: se armazena pedidos, formulários de contato ou contas, o guia da Autoridade Saudita de Dados e Inteligência Artificial (SDAIA) sobre incidentes de violação de dados pessoais exige que o controlador notifique a autoridade competente em até 72 horas após tomar conhecimento de uma violação que possa prejudicar os dados ou as pessoas a quem eles pertencem.

A visão da Origami

Muitos sites de empresas são construídos em WordPress e depois tratados como um folheto impresso: o desenvolvedor entrega, o dono paga e ninguém pergunta quem vai mantê-lo atualizado. Esta falha lembra que um site é um sistema vivo em um servidor exposto à internet, e que o intervalo entre a publicação de uma correção e a chegada de um atacante agora é medido em horas. A verdadeira pergunta não é se o WordPress é seguro, já que ele corrigiu o bug e enviou a correção para todos os ramos até a 4.7. É quem, na sua empresa, é responsável por instalá-la.

Por isso, achamos que um contrato de manutenção de site deve definir um prazo máximo para instalar atualizações críticas de segurança, exigir uma cópia de staging onde as atualizações sejam testadas antes do site em produção e manter backups regulares armazenados fora do próprio servidor. E se as atualizações continuam sendo adiadas porque o tema foi personalizado de um jeito que quebra a cada atualização, isso é um problema de como o site foi construído, não do WordPress, e merece ser resolvido antes da próxima falha.

Resumo: três passos

  • Hoje: abra o painel administrativo e confirme que a versão é a 7.1.2 ou a versão corrigida do seu ramo, e que o Elementor está na 4.3.2 ou posterior.
  • Esta semana: peça ao desenvolvedor ou à hospedagem que faça uma varredura no servidor em busca de arquivos PHP desconhecidos e que confirme por escrito que as atualizações automáticas estão ativadas.
  • Este mês: inclua no contrato de manutenção um prazo máximo para instalar atualizações de segurança e nomeie a pessoa responsável por isso.

Fontes