Se você usa o plugin AI Engine no seu site WordPress e em algum momento ativou a função “No-Auth URL”, precisa tratar isso hoje como um incidente de segurança – não apenas como “mais uma atualização de plugin”. Estamos falando da WordPress AI Engine vulnerability catalogada como CVE-2025-11749, com gravidade CVSS 9.8 (crítica), que pode levar a takeover completo do site.
A história em uma frase: ativar o “No-Auth URL” era como criar uma “porta dos fundos” secreta para o seu site – mas um erro de implementação fez o plugin publicar tanto o endereço dessa porta quanto a senha (o bearer token) na “lista telefônica” pública do WordPress, o índice da REST API em /wp-json/.
O “asterisco”: quem realmente está em risco
Aqui entra o “asterisco” que muda tudo: essa vulnerabilidade não atinge automaticamente todos os mais de 100 mil sites que usam o plugin AI Engine.
Ela só se torna crítica quando o administrador:
- entrou nas configurações do MCP (Model Context Protocol) do plugin;
- ativou manualmente a opção “No-Auth URL” (desabilitada por padrão);
- e passou a usar URLs especiais que permitem que agentes de IA (como ChatGPT ou Claude) conversem com o site sem autenticação tradicional.
Se você nunca mexeu nessa opção, o risco é bem menor – mas vale, mesmo assim, atualizar e revisar as configurações.
Se você lembra de ter ativado o “No-Auth URL” para facilitar integrações com agentes de IA, então o alerta é máximo: considere que seu bearer token pode já estar exposto publicamente e que alguém pode ter usado isso para entrar no seu site.
Como o ataque funciona: uma senha no índice público
O AI Engine integra o MCP (Model Context Protocol), que basicamente permite que agentes de IA “dirijam” o seu WordPress: executar comandos, gerenciar mídia, editar usuários, publicar conteúdo… é quase um painel de administrador controlado por IA.
Para isso, o plugin usa um bearer token – pense nisso como uma “senha mestra” que autoriza o agente a executar comandos privilegiados. Até aí, tudo bem. O problema da CVE-2025-11749 está em como essa senha mestra foi exposta:
- O plugin registra rotas na REST API com o token embutido na própria URL, algo como:
/wp-json/mcp/v1/<bearer_token>/messages
- O desenvolvedor esqueceu de marcar essas rotas como “invisíveis” no índice da API, não usando o parâmetro
show_in_index => false. - Resultado: o próprio WordPress passou a listar essas URLs – com o token completo – no índice público em
/wp-json/.
Na prática, um atacante não autenticado pode:
- acessar o índice da API em
/wp-json/; - localizar as rotas MCP que contêm o token;
- copiar o bearer token;
- usá-lo para se autenticar no endpoint MCP e chamar comandos de alto privilégio, como
wp_update_user.
Com esse comando, o invasor pode simplesmente mudar o próprio papel de usuário para administrador, criar uma nova conta admin ou fazer qualquer ação que um admin legítimo faria. É um cenário clássico de Account Takeover com escalonamento de privilégio completo: upload de backdoors em plugins/temas, injeção de spam, redirecionamentos maliciosos, tudo o que você não quer ver no seu site.
Ação urgente: atualizar e rotacionar o token
A boa notícia: o desenvolvedor respondeu rápido e lançou a versão 3.1.4 do AI Engine, que corrige a WordPress AI Engine vulnerability. A má notícia: apenas atualizar não basta para quem já usou o “No-Auth URL”.
A correção técnica foi simples e elegante: as rotas “No-Auth URL” agora são registradas com show_in_index => false, o que impede que o bearer token continue aparecendo no índice /wp-json/. Isso evita novas exposições — mas não apaga o passado. Se o token já foi exposto, você precisa tratá-lo como comprometido.
O plano mínimo de resposta deve ter duas etapas:
- Atualizar o plugin para a versão 3.1.4 (ou superior)
- Vá em Plugins → Atualizações e garanta que o plugin AI Engine está na versão corrigida.
- Se você usa soluções de segurança como Wordfence, aproveite para verificar se as regras de firewall estão ativas.
- Gerar um novo token – ou seja, “rotacionar a chave”
- Acesse as configurações do AI Engine, na seção de MCP.
- Localize o campo do bearer token.
- Gere um novo token e salve – isso é literalmente rotacionar a chave, invalidando a antiga.
- Se você não precisa mesmo do “No-Auth URL”, considere desativar essa opção de vez.
Como etapa adicional de higiene de segurança, vale:
- revisar a lista de usuários e ver se há novos administradores suspeitos;
- checar logs de acesso e de ações administrativas;
- trocar senhas críticas e garantir 2FA no painel de hospedagem e outros serviços.
Boas práticas para integrar IA ao WordPress
Esse incidente deixa uma mensagem clara para quem está empolgado com IA no CMS: plugins de IA que ganham poderes de admin remoto precisam ser tratados como chaves do cofre – não como simples “integrações bonitinhas”.
Algumas lições práticas:
- Evite habilitar recursos “No-Auth” se você não entende 100% o impacto.
- Considere sempre que qualquer URL exposta pode acabar em logs, caches e índices públicos.
- Trate bearer tokens como segredos: renove periodicamente, limite escopo e desative o que não usa.
- Mantenha uma rotina rígida de atualização e monitore boletins de segurança de fontes como a Wordfence.
A corrida por produtividade com IA é real – mas segurança ainda precisa vir primeiro. Nesse caso, um simples esquecimento de show_in_index => false em rotas sensíveis quase transformou um assistente de IA em uma porta escancarada para o seu painel de administração.
