WordPress corrige Comment2Shell (CVE-2026-93485) com adesivo 7.1.1 para o núcleo 4.7–7.1

Em 17 de setembro, o WordPress publicou um adesivo que corrige uma vulnerabilidade no núcleo —registrada como CVE-2026-93485 e batizada pela comunidade como "Comment2Shell" — que permitia a um visitante anônimo publicar um comentário que continha um script oculto. Se um administrador autenticado abria depois a página com esse comentário, o código poderia aproveitar a sessão do administrador para executar ações com privilégios sobre o servidor, incluindo a subida de um plugin malicioso que atua como web shell. O WordPress resolveu o problema na versão 7.1.1 e alertou os responsáveis por sites para atualizar imediatamente. A nota de segurança oficial do WordPress e a ficha CVE no catálogo público recolhe os detalhes básicos.

Os fatos confirmados são os seguintes: a falha afeta versões do núcleo desde 4.7 até 7.1; o WordPress lançou correções específicas para cada ramo (por exemplo, 7.1 → 7.1.1, 7.0 → 7.0.5, 6.9 → 6.9.8 e outros ramos até 4.7.36); a vulnerabilidade foi relatada pelo pesquisador Rafie Muhammad e descrita publicamente em uma publicação técnica; Patchstack designou e documentou a entrada e deu-lhe uma pontuação de 7.1/10 na escala CVSS; e, segundo as declarações públicas até a data, não há evidência conhecida de exploração em ataques massivos ou figura em listas governamentais de exploração ativa. Patchstack mantém uma ficha com a análise e a classificação.

Tecnicamente, a vulnerabilidade surge de uma descoordenação entre dois passos distintos no tratamento de comentários: WordPress valida e filtra HTML "perigroso" quando o comentário é gravado, e depois aplica um reformatado (sanitizado/escapado) suplementar quando o comentário é mostrado na página. O vetor de ataque aproveitou um espaço entre esses processos: ao introduzir deliberadamente um salto de linha dentro do atributo de uma marca HTML permitida no comentário, a fase de renderização fragmenta a etiqueta e move o texto do atacante para uma posição que o navegador interpreta como um gerenciador de eventos (por exemplo, um onload ou similar). Esse gerenciador é executado automaticamente ao carregar a página, sem interação do usuário. A execução do programa ocorre no contexto do navegador de quem carrega a página e herda o nível de acesso dessa sessão.

Para escalar a partir de execução no navegador para execução de código no servidor, são necessárias duas condições adicionais, ambas confirmadas pela pesquisa: primeiro, a vítima que abre a página deve ser um administrador autenticado; segundo, o programa deve realizar ações que utilizem a sessão do administrador para aumentar um plugin malicioso (ou ativar rotas equivalentes de importação de código). A técnica de subir um plugin que contenha um web shell é um caminho bem conhecido para converter uma sessão de administrador em controle persistente do servidor.

Importante: a vulnerabilidade não afeta todos os sites por igual. Funciona apenas em sites cujo tema (ou esquema de comentários) formateia os comentários da forma vulnerável: ocorre em temas block e em alguns temas clássicos que replicam o mesmo reformatado. Além disso, embora o WordPress descreveu a falha como "explotável sujeito à aprovação de comentários", a moderação por defeito e as regras de primeira vez para comentar não constituem um controle infalível: a configuração pode deixar comentários sem moderação, e em muitos cenários a barreira de moderação pode ser sorteada ou não estar ativada. Patchstack resumiu isso com a observação de que "a moderação não é um controle de segurança".

Sobre o risco real: confirmado está que a vulnerabilidade permite, em condições específicas, uma escalada de execução em servidor se um administrador visitar a página afetada. O que ainda é incerto ou uma estimativa razoável é se atores maliciosos já aproveitaram Comment2Shell em campanhas reais - até agora não há evidência pública de exploração - e que número de instalações em produção cumprem todas as condições necessárias (tema vulnerável, comentários públicos alcançáveis, administradores que visitem a página). Mesmo na ausência de prova de exploração maciça, a combinação de facilidade de publicação de comentários e administradores que visitam páginas públicas torna o defeito operacional e digno de atenção imediata.

O que deve fazer agora um responsável pelo site WordPress: o primeiro e obrigatório é atualizar o núcleo à versão corrigida para seu ramo. As versões a instalar são, no mínimo: 7.1 → 7.1.1; 7.0 → 7.0.5; 6.9 → 6.9.8; e, se usar ramos anteriores até 4.7, instalar a versão adesivo disponível para esse ramo (as correcções foram publicadas para os ramos com suporte). A atualização fecha a vulnerabilidade, mas não restaura mudanças que um atacante já tivesse realizado.

Se você não puder aplicar a atualização imediatamente, veja o vetor bloqueando a publicação de novos comentários públicos: feche os comentários em itens antigos, ou desligue os comentários de forma global até atualizar. Um firewall de aplicativos web (WAF) ou plugins de segurança (por exemplo, regras comerciais em Cloudflare, Sucuri ou regras de mod_security) podem interceptar e bloquear a carga do comentário malicioso, embora a eficácia depende das assinaturas e regras disponíveis. Não confie apenas na moderação de comentários como defesa.

Se você suspeitar que seu site pode ter sido comprometido antes do adesivo, faça as seguintes verificações concretas: procure plugins ou arquivos novos ou modificados em wp-content/plugins e wp-content/uploads; verifique listas de plugins ativos e compare com inventários anteriores; use ferramentas como 'wp core verify-checksums' (WP-CLI) para detectar arquivos de núcleo alterados; escanee o site com motores de reputação e malware (Wordfence, Sucuri, VírusTotal para arquivos suspeitos); verifique cron jobs, contas de usuário e entradas invulgares nos logs de acesso/erros do servidor; e mude as senhas administrativas e invalide sessões ativas (cerrar todas as sessões). Todo trabalho de limpeza deve ser realizado sobre uma cópia ou manutenção, e é recomendável restaurar de uma cópia de segurança limpa se for detectado compromisso.

Como medidas preventivas adicionais a aplicar após a correção: limite a capacidade de instalar plugins/themes a poucas contas de confiança, habilite a autenticação multifator para contas administrativas, restrinja o acesso a /wp-admin por IP ou através de autenticação HTTP adicional se possível, e mantenha actualizadas as extensões e temas. Evalue a adoção de um WAF gerenciado e de alertas de integridade de arquivos para detectar manipulações precoces.

Fontes e documentação técnica pública sobre o adesivo e classificação estão disponíveis na nota do WordPress e no prontuário de Patchstack; a entrada CVE pública oferece a designação oficial da vulnerabilidade. Verifique esses anúncios e programe a atualização assim que possível: os adesivos estão disponíveis e aplicar a correção é a ação que elimina a janela de exposição. RCM CVE (Mitre) e Patchstack - CVE-2026-93485 Contém mais detalhes técnicos e referências.