Um IDOR no n8n-mcp deixou qualquer tenant autenticado ler as credenciais de todos os outros. O bug é literalmente adivinhar números sequenciais. CVE-2026-54052 (atribuído pela Manifold Security; pendente de publicação no NVD), CVSS 9.9 segundo o GitHub Advisory (GHSA-j6r7-6fhx-77wx) — e é o quinto problema de segurança multi-tenant no mesmo projeto em 2026. O padrão é claro: a camada de roteamento foi protegida, a camada de persistência nunca foi.
O bug: IDs sequenciais sem verificação de propriedade
A tabela workflow_versions no SQLite não tinha coluna de tenant. Todos os backups de todos os tenants compartilhavam uma tabela com IDs inteiros sequenciais. Quando um tenant chamava n8n_workflow_versions com um ID, o manipulador (handler) consultava sem verificação de propriedade. Fornecesse qualquer inteiro, recebia o snapshot de qualquer outro tenant. A enumeração era trivial — basta incrementar o ID.
O que estava exposto: cópias instantâneas (snapshots) de versões de workflow incluem definições completas de nós. Isso significa API keys, Bearer tokens, authorization headers, URLs de webhook e referências de credenciais configuradas nos nós. O atacante também podia deletar, truncar — apagar TODOS os backups de TODOS os tenants globalmente — ou importar o snapshot de outro tenant na própria instância, efetivamente fazendo reversão (rollback) de um workflow alheio.
Segundo Francisco Rosales, da Manifold Security, que descobriu a vulnerabilidade, o acesso era direto e sem qualquer barreira além de autenticação no tenant próprio. Segundo a Manifold Security, o mantenedor Romuald Czlonkowski reconheceu, confirmou e publicou o patch em menos de uma semana.
O escopo: multi-tenant HTTP, não uso local
O n8n-mcp é um servidor MCP (Model Context Protocol) construído pela comunidade que dá a assistentes de IA — Claude Desktop, Claude Code, Cursor, Windsurf — acesso à documentação de nós do n8n. O n8n, plataforma de automação de workflows, tem 193 mil estrelas no GitHub. O n8n-mcp, servidor MCP construído pela comunidade, tem mais de 21 mil estrelas e 150 mil downloads semanais no npm, segundo o GitHub e o npm.
O escopo do impacto é específico: afeta APENAS implantações (deployments) HTTP multi-tenant com ENABLE_MULTI_TENANT=true. NÃO afeta uso local/stdio como Claude Desktop ou single-tenant. O caso de uso mais comum — desenvolvedores rodando n8n-mcp localmente — não é afetado.
Mas para quem opera implantações multi-tenant, a exposição é total. Cada credencial configurada em cada nó de cada workflow de cada tenant estava acessível a qualquer outro tenant autenticado.
O padrão: cinco CVEs, mesma raiz
Este é o quinto problema de segurança multi-tenant no n8n-mcp em 2026. Os anteriores:
- CVE-2026-39974 (CVSS 8.5): SSRF via instance-URL header
- CVE-2026-45707 (CVSS 8.1): recuo (fallback) de credencial para instância do operador
- CVE-2026-44694 (CVSS v3.1 9.1; v4.0: 7.2): SSRF em webhook/API paths
- Path traversal + SSRF + telemetry leak (CVSS 8.3, sem CVE atribuído)
O padrão é consistente e estrutural: a camada de roteamento multi-tenant foi protegida, mas a camada de persistência local (SQLite) nunca recebeu isolamento. Cada correção endereçou o vetor específico — SSRF no header, SSRF no path, recuo (fallback) de credencial — sem auditar a camada de dados subjacente.
Segundo a Manifold Security, o modelo de ameaça (threat model) do projeto já listava "cross-tenant bleed" como risco conhecido, alegando que era mitigado via header-derived credentials. A mitigação cobria o roteamento, não o banco local. É o equivalente a trancar a porta da frente e deixar a janela aberta — repetidas vezes.
O patch e o que ele resolve
O n8n-mcp v2.56.1 adiciona a coluna instance_id à tabela workflow_versions e escopa toda query ao tenant chamador. Uma migração one-time roda no upgrade e limpa cópias de segurança (backups) previamente não escopados.
O patch é correto e completo para este CVE específico. Mas não resolve o padrão. Enquanto a persistência local não for auditada sistematicamente para isolamento de tenant, o próximo vetor aparece na próxima tabela sem escopo.
MCP é o novo perímetro
A lição para quem constrói infraestrutura para agentes de IA: o MCP é o novo perímetro. Cada servidor MCP que dá a um agente acesso a dados ou ferramentas é uma superfície de ataque. E o isolamento multi-tenant precisa ser end-to-end, não apenas na camada de roteamento.
O n8n-mcp tem 150 mil downloads semanais no npm, segundo o npm. Cada um desses downloads é um potencial ponto de entrada para um agente de IA em uma infraestrutura corporativa. Quando o agente acessa dados via MCP, a segurança desse canal é tão crítica quanto a segurança da API que o agente consome.
Na Tech86, aplicamos esse princípio na prática: nosso EDR gerenciado monitora acessos anômalos em camadas de persistência local — exatamente o tipo de padrão que esse IDOR representa. Se um tenant começa a enumerar IDs sequenciais em uma tabela SQLite, nosso monitoramento detecta e alerta antes que a enumeração se torne exfiltração. Quando o isolamento na camada de dados falha, a detecção comportamental é a última linha de defesa.