Un IDOR en n8n-mcp dejó que cualquier tenant autenticado leyera las credenciales de todos los demás. El bug es literalmente adivinar números secuenciales. CVE-2026-54052 (asignado por Manifold Security; pendiente de publicación en el NVD), CVSS 9.9 según el GitHub Advisory (GHSA-j6r7-6fhx-77wx), y es el quinto problema de seguridad multi-tenant en el mismo proyecto en 2026. El patrón es claro: la capa de enrutamiento fue protegida, la capa de persistencia nunca lo fue.
El bug: IDs secuenciales sin verificación de propiedad
La tabla workflow_versions en SQLite no tenía columna de tenant. Todos los backups de todos los tenants compartían una tabla con IDs enteros secuenciales. Cuando un tenant llamaba n8n_workflow_versions con un ID, el manipulador (handler) consultaba sin verificación de propiedad. Bastaba proporcionar cualquier entero para recibir el snapshot de cualquier otro tenant. La enumeración era trivial: basta incrementar el ID.
Lo que estaba expuesto: las instantáneas (snapshots) de versiones de workflow incluyen definiciones completas de nodos. Eso significa API keys, Bearer tokens, authorization headers, URLs de webhook y referencias de credenciales configuradas en los nodos. El atacante también podía eliminar, truncar, borrar TODOS los backups de TODOS los tenants globalmente, o importar el snapshot de otro tenant en su propia instancia, haciendo efectivamente una reversión (rollback) de un workflow ajeno.
Según Francisco Rosales, de Manifold Security, quien descubrió la vulnerabilidad, el acceso era directo y sin barrera alguna más allá de la autenticación en el tenant propio. Según Manifold Security, el mantenedor Romuald Czlonkowski lo reconoció, lo confirmó y publicó el parche en menos de una semana.
El alcance: multi-tenant HTTP, no uso local
El n8n-mcp es un servidor MCP (Model Context Protocol) construido por la comunidad que da a los asistentes de IA, Claude Desktop, Claude Code, Cursor, Windsurf, acceso a la documentación de nodos de n8n. El n8n, plataforma de automatización de workflows, tiene 193 mil estrellas en GitHub. El n8n-mcp, servidor MCP construido por la comunidad, tiene más de 21 mil estrellas y 150 mil descargas semanales en npm, según GitHub y npm.
El alcance del impacto es específico: afecta SOLO despliegues (deployments) HTTP multi-tenant con ENABLE_MULTI_TENANT=true. NO afecta el uso local/stdio como Claude Desktop o single-tenant. El caso de uso más común, desarrolladores ejecutando n8n-mcp localmente, no es afectado.
Pero para quien opera despliegues multi-tenant, la exposición es total. Cada credencial configurada en cada nodo de cada workflow de cada tenant estaba accesible para cualquier otro tenant autenticado.
El patrón: cinco CVEs, la misma raíz
Este es el quinto problema de seguridad multi-tenant en n8n-mcp en 2026. Los anteriores:
- CVE-2026-39974 (CVSS 8.5): SSRF vía header instance-URL
- CVE-2026-45707 (CVSS 8.1): repliegue (fallback) de credencial a la instancia del operador
- CVE-2026-44694 (CVSS v3.1 9.1; v4.0: 7.2): SSRF en webhook/API paths
- Path traversal + SSRF + telemetry leak (CVSS 8.3, sin CVE asignado)
El patrón es consistente y estructural: la capa de enrutamiento multi-tenant fue protegida, pero la capa de persistencia local (SQLite) nunca recibió aislamiento. Cada corrección abordó el vector específico (SSRF en el header, SSRF en el path, repliegue (fallback) de credencial) sin auditar la capa de datos subyacente.
Según Manifold Security, el modelo de amenazas (threat model) del proyecto ya listaba el "cross-tenant bleed" como riesgo conocido, alegando que era mitigado vía header-derived credentials. La mitigación cubría el enrutamiento, no la base local. Es el equivalente a cerrar con llave la puerta principal y dejar la ventana abierta, repetidas veces.
El parche y lo que resuelve
El n8n-mcp v2.56.1 agrega la columna instance_id a la tabla workflow_versions y limita toda query al tenant llamador. Una migración one-time corre en el upgrade y limpia copias de seguridad (backups) previamente sin ese alcance.
El parche es correcto y completo para este CVE específico. Pero no resuelve el patrón. Mientras la persistencia local no sea auditada sistemáticamente para aislamiento de tenant, el próximo vector aparece en la próxima tabla sin alcance.
MCP es el nuevo perímetro
La lección para quien construye infraestructura para agentes de IA: el MCP es el nuevo perímetro. Cada servidor MCP que da a un agente acceso a datos o herramientas es una superficie de ataque. Y el aislamiento multi-tenant necesita ser end-to-end, no solo en la capa de enrutamiento.
El n8n-mcp tiene 150 mil descargas semanales en npm, según npm. Cada una de esas descargas es un potencial punto de entrada para un agente de IA en una infraestructura corporativa. Cuando el agente accede a datos vía MCP, la seguridad de ese canal es tan crítica como la seguridad de la API que el agente consume.
En Tech86 aplicamos este principio en la práctica: nuestro EDR gestionado monitorea accesos anómalos en capas de persistencia local, exactamente el tipo de patrón que este IDOR representa. Si un tenant empieza a enumerar IDs secuenciales en una tabla SQLite, nuestro monitoreo detecta y alerta antes de que la enumeración se convierta en exfiltración. Cuando el aislamiento en la capa de datos falla, la detección conductual es la última línea de defensa.
Continúa en el tema
Segurança de Agentes de IA: Prompt Injection, Worms e Supply Chain →