Falha crítica no WordPress passa de tentativas de exploração a ataques ativos
A vulnerabilidade CVE-2026-87902, que afeta determinadas instalações do WordPress, começou a ser explorada poucas horas depois de sua divulgação pública. O alerta é da empresa de segurança Patchstack, que identificou uma escalada das tentativas iniciais de reconhecimento para comprometimentos ativos.
Com pontuação CVSS de 9,2, a falha envolve uma passagem de caminho na resolução de templates de página. Em condições específicas, um invasor sem autenticação pode induzir o WordPress a carregar um arquivo PHP local que possa ser lido pela conta do servidor web, mesmo que esteja fora dos diretórios do tema ativo. Se a cadeia de exploração for concluída, o problema pode permitir execução remota de código.
O ataque depende de requisitos particulares. Entre eles, o nome do diretório principal do tema em uso precisa começar com “page-“, e o servidor deve ter acesso de leitura ao arquivo PHP escolhido pelo invasor. Portanto, a presença da vulnerabilidade não significa que qualquer site WordPress possa ser comprometido automaticamente: a exploração depende da combinação entre a estrutura do tema e as configurações do ambiente.
Uma das técnicas observadas utiliza o arquivo `pearcmd.php`, associado ao PEAR, para avançar até a execução de código. Esse caminho pode funcionar quando a diretiva `register_argc_argv` está habilitada. Segundo as informações divulgadas, a imagem oficial do PHP para Docker está entre os ambientes afetados. A configuração padrão do cPanel também pode estar vulnerável quando utiliza versões do PHP anteriores à 8.5.
Entre os temas com estruturas de diretório potencialmente relevantes estão os antigos Twenty Twelve e Twenty Fourteen, além de opções de terceiros como Neve, Hestia e Sydney. A simples utilização de um desses temas, porém, não confirma por si só que o site esteja exposto: é necessário verificar a estrutura instalada, a versão do WordPress e as condições do servidor.
A correção foi disponibilizada em 22 de setembro, na versão 7.1.2 do WordPress. O ajuste também foi levado a versões anteriores, incluindo a série 4.7.x. Administradores devem atualizar a plataforma para uma versão corrigida compatível com sua instalação e confirmar se a atualização foi aplicada corretamente.
A Patchstack afirma que os primeiros payloads identificados reproduziam exatamente o comportamento tratado pelo patch. Isso sugere que os responsáveis pelas tentativas tiveram acesso à diferença entre o código vulnerável e o código corrigido, em vez de terem descoberto a falha de forma independente.
A atividade começou com um pequeno grupo de endereços IP e tinha como objetivo inicial identificar servidores suscetíveis. Em seguida, os atacantes passaram a verificar se era possível incluir o `pearcmd.php` e, na etapa final, usar esse arquivo para gravar conteúdo PHP no servidor e executar comandos remotamente.
De acordo com a empresa de segurança, o volume de tráfego direcionado à vulnerabilidade ultrapassou em mais de dez vezes o observado na primeira noite. A expansão da quantidade de sites atingidos e a progressão em três etapas indicam que a operação deixou de ser apenas uma sondagem e passou a resultar em invasões.
Como reduzir o risco
A medida mais importante é instalar a atualização de segurança do WordPress sem demora. Sites que não possam ser atualizados imediatamente devem ser tratados como prioridade: a equipe responsável precisa avaliar a exposição do ambiente, limitar acessos desnecessários e considerar medidas temporárias de proteção no servidor ou no firewall de aplicações.
Também é recomendável conferir a versão do PHP e as configurações do ambiente de hospedagem. A diretiva `register_argc_argv` merece atenção especial, assim como a disponibilidade de arquivos PHP locais que possam ser lidos pela conta do servidor web. Alterações de configuração devem ser feitas com cautela para evitar a interrupção de funcionalidades legítimas.
Após a atualização, administradores devem examinar os registros do servidor em busca de requisições incomuns relacionadas à resolução de templates, ao arquivo `pearcmd.php` ou à criação inesperada de arquivos PHP. A presença desses sinais não confirma isoladamente uma invasão, mas justifica uma investigação detalhada.
Se houver indícios de comprometimento, é importante isolar o site quando possível e preservar registros para análise. A equipe deve procurar arquivos desconhecidos, alterações recentes em temas e plugins, contas administrativas não reconhecidas e tarefas agendadas suspeitas. Senhas e chaves de acesso também devem ser renovadas a partir de um dispositivo confiável.
Manter cópias de segurança recentes e armazenadas separadamente ajuda a recuperar o serviço caso seja necessário reconstruir a instalação. Ainda assim, restaurar um backup sem corrigir a vulnerabilidade pode permitir que o mesmo ataque se repita. Por isso, a atualização, a revisão do ambiente e a verificação de sinais de invasão precisam fazer parte do processo de resposta.
A existência de ferramentas públicas de varredura pode facilitar a identificação de sites vulneráveis e ampliar a escala dos ataques. Diante do aumento observado, não é prudente esperar por sinais de exploração para agir: organizações que usam WordPress devem verificar suas instalações e aplicar as correções o quanto antes.