WordPress sob ataque: atualizar para 7.1.2 é só o primeiro passo

O Centro Canadense de Cibersegurança atualizou em 25 de setembro de 2026 o alerta sobre a CVE-2026-87902: há relatos de exploração contra instalações WordPress anteriores à 7.1.2, e a falha entrou no catálogo de vulnerabilidades exploradas da CISA. O aviso foi publicado em 23 de setembro, depois da distribuição da correção pelo projeto.

Para saber se um site está exposto, é preciso conferir a versão do núcleo e compará-la com a correção do seu ramo. Atualizar bloqueia a exploração dessa falha em novas requisições, mas não apaga arquivos eventualmente criados antes do patch nem prova que não houve acesso indevido. Por isso, a resposta inclui examinar registros de requisições e alterações no servidor.

Quais versões exigem atualização

O boletim oficial do WordPress, publicado em 22 de setembro, relaciona como afetadas as versões de 4.7.0 a 7.1.1 e identifica 7.1.2 como correção do ramo mais recente. Também enumera patches para ramos antigos; a comparação deve ser feita com a versão realmente instalada, e não apenas com o número 7.1.2:

• Ramos 7.1 e 7.0: versões corrigidas 7.1.2 e 7.0.6.
• Ramos 6.9, 6.8, 6.7 e 6.6: versões corrigidas 6.9.9, 6.8.10, 6.7.9 e 6.6.9.
• Ramos 6.5, 6.4, 6.3, 6.2, 6.1 e 6.0: versões corrigidas 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14 e 6.0.16.
• Ramos 5.9 a 5.0: correções 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26 e 5.0.29.
• Ramos 4.9, 4.8 e 4.7: correções 4.9.33, 4.8.32 e 4.7.37.

O backport protege contra esta falha específica em um ramo antigo, mas só a versão mais recente recebe suporte ativo. Em sites com atualização automática, confirme a versão em execução depois do processo: a configuração para atualizar não demonstra que o pacote foi aplicado. O mesmo cuidado vale para instalações que compartilham um núcleo em uma rede de sites.

Quando a inclusão de arquivo vira execução de código

A falha fica na resolução de modelos de página do WordPress. Uma requisição sem autenticação pode influenciar o caminho usado por get_page_template() e fazer o núcleo incluir um arquivo PHP local legível fora dos diretórios do tema ativo. O problema está no núcleo, mas o tema e o ambiente do servidor determinam se a cadeia conhecida é alcançável.

Na exploração demonstrada, uma página publicada precisa chegar à resolução do modelo, e o tema filho ou pai ativo deve ter, na sua raiz, um diretório cujo nome comece por page-, como page-templates. O arquivo visado deve existir e estar acessível ao processo web. Se um modelo personalizado for escolhido antes do caminho manipulado, ou se controles do sistema de arquivos bloquearem a leitura, essa rota específica pode não funcionar.

Inclusão de arquivo e execução remota de código não são sinônimos. A rota pública que usa o componente PEAR exige um pearcmd.php legível e register_argc_argv ativado no PHP que atende à web; gravar um novo arquivo também exige um local com permissão de escrita. Desligar essa configuração ou restringir o acesso aos arquivos pode dificultar a técnica conhecida, mas não corrige a validação de caminho em um WordPress ainda vulnerável.

O que a atualização resolve

Aplique o patch do ramo instalado ou migre para a versão atual e confirme o número após a atualização. Em caso de suspeita, preserve cópias dos registros e dos arquivos incomuns antes de alterá-los: seus horários e conteúdos ajudam a reconstruir a sequência do incidente. A janela relevante começa quando o site executava uma versão afetada e termina com a confirmação da correção, não com o clique no botão de atualizar.

Uma resposta baseada apenas no painel do WordPress deixa uma pergunta em aberto: houve requisições maliciosas enquanto a versão antiga ainda estava no ar? A atualização bloqueia a exploração dessa rota em novas requisições, mas não reverte uma gravação feita anteriormente nem encerra uma investigação de persistência. Se não houver evidência de invasão, isso ainda precisa ser distinguido da simples ausência de registros disponíveis.

Quais indícios procurar nos logs

A análise técnica da PowerSEC descreve tentativas com page_id e pagename na mesma requisição, inclusive sequências de travessia codificadas como %2e%2e, %252e%252e e %252f. Referências a pearcmd.php, config-create ou config-show no mesmo intervalo ajudam a reconhecer a tentativa de transformar a inclusão em gravação de arquivo. Pedidos para incluir um PHP comum do próprio núcleo também podem ser sondagens, e não prova de que o arquivo malicioso foi executado.

Consulte registros HTTP, do firewall de aplicações, do proxy e da hospedagem quando existirem, correlacionando horário, endereço de origem e destino. Há variantes com GET e POST; logs de acesso convencionais normalmente não registram o corpo do POST, onde o valor suspeito pode estar. Portanto, não encontrar pagename no log de acesso não descarta uma tentativa; a visibilidade depende do que cada camada registrou e de quanto tempo esses dados foram guardados.

O que verificar nos arquivos após o patch

Procure arquivos PHP novos ou modificados sem explicação em diretórios graváveis pelo processo web, sobretudo /tmp, /var/tmp, wp-content/uploads e áreas de cache. Compare arquivos do núcleo, temas e plugins com cópias confiáveis e examine plugins de uso obrigatório e contas administrativas inesperadas se houver sinal de gravação ou execução. Nomes divulgados em análises de ataque servem como pista, mas um invasor pode escolher outro nome; horário, conteúdo, proprietário e permissões dão mais contexto.

Um pedido suspeito indica tentativa, não necessariamente sucesso. Um arquivo PHP criado ou executado sem autorização muda o estado da investigação e justifica tratar o servidor como possivelmente comprometido, inclusive fora da árvore do WordPress. Os alertas públicos registram exploração em campo e correções disponíveis, mas não fornecem uma contagem confiável de sites invadidos. Em cada instalação, a conclusão depende da versão que estava ativa, dos registros preservados e das alterações encontradas.

Leia também:

• Chave exposta no SageMaker permite executar código — atualizar não basta
• Claude libera 10 mil vagas para cientistas — plano gratuito exige líder verificado
• Plano Claude para cientistas: a gratuidade termina após 12 meses