n8n-MCP: Incorrect authorization can expose default-scope workflow version backups in multi-tenant HTTP mode
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.57.4, multi-tenant HTTP mode with ENABLE_MULTI_TENANT=true could allow an authenticated tenant to access default-scope workflow_versions backups instead of being confined to the tenant scope, exposing or deleting workflow-version backups from prior single-tenant deployments or migrations. This issue is fixed in version 2.57.4.
n8n-MCP: Cross-tenant access to workflow version backups in multi-tenant HTTP deployments
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.56.1, in HTTP mode with multi-tenancy enabled through ENABLE_MULTI_TENANT=true, n8n-mcp's local workflow version history backups were not isolated per tenant, allowing an authenticated tenant to read workflow version snapshots belonging to other tenants and delete or destroy other tenants' stored backups, including full node definitions, credential references, and authorization headers. This issue is fixed in version 2.56.1.
n8n-MCP: Workflow telemetry sanitizer could retain partial values from URL-shaped node parameters
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.51.3, the workflow telemetry sanitizer could retain partial fragments of URL-shaped node parameters before sending workflow data to the project's anonymous telemetry backend. Values placed in HTTP-Request-style node parameters — such as customer or tenant identifiers, short secrets embedded in query strings, and signed request parameters — could therefore appear in stored telemetry, contrary to the collection boundary documented in PRIVACY.md. This vulnerability is fixed in 2.51.3.
n8n-MCP: Multi-tenant MCP requests fall back to process-level n8n credentials when tenant headers are absent or incomplete
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.51.2, when ENABLE_MULTI_TENANT=true, the HTTP transport documents that the target n8n instance is selected per-request from x-n8n-url / x-n8n-key headers. Requests that omitted those headers — or supplied only one of them — silently fell back to the process-level N8N_API_URL / N8N_API_KEY credentials configured for the operator's own n8n instance. As a result, an authenticated MCP tenant could cause n8n management calls to execute against the operator's instance instead of its own. This affects HTTP-mode deployments of
n8n-MCP: Authenticated SSRF in n8n-mcp webhook and API client paths
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. From version 2.18.7 to before version 2.50.2, there is an authenticated server-side request forgery vulnerability affecting the webhook trigger tools, the n8n API client (N8N_API_URL), and per-request URLs supplied via the x-n8n-url header in multi-tenant HTTP mode. This issue has been patched in version 2.50.2.
n8n-MCP: Sensitive MCP tool-call arguments logged on authenticated requests in HTTP mode
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to version 2.47.13, when n8n-mcp runs in HTTP transport mode, authenticated MCP tools/call requests had their full arguments and JSON-RPC params written to server logs by the request dispatcher and several sibling code paths before any redaction. When a tool call carries credential material — most notably n8n_manage_credentials.data — the raw values can be persisted in logs. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipeli
n8n-MCP Logs Sensitive Request Data on Unauthorized /mcp Requests
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to version 2.47.11, when n8n-mcp runs in HTTP transport mode, incoming requests to the POST /mcp endpoint had their request metadata written to server logs regardless of the authentication outcome. In deployments where logs are collected, forwarded to external systems, or viewable outside the request trust boundary (shared log storage, SIEM pipelines, support/ops access), this can result in disclosure of: bearer tokens from the Authorization header, per-tenant API keys from the, x-n8n-key header in multi-tenant setups, JSON
n8n-mcp affected by path traversal, redirect-following SSRF, and telemetry payload exposure
## Impact
`n8n-mcp` versions before 2.50.1 contained three independently-reported issues affecting deployments that run the n8n API integration:
1. **Caller-supplied identifiers were not validated before being used as URL path segments** by the n8n API client. An authenticated MCP caller passing a crafted workflow id could cause outbound requests carrying the configured n8n API key to land on other same-origin endpoints, bypassing handler-level access controls (including `DISABLED_TOOLS`).
2. **Validated webhook, form, and chat trigger URLs followed redirects.** A URL that passed initial validation could redirect the outbound request to a
n8n-MCP: IPv4-mapped IPv6 addresses bypass SSRF protection in validateUrlSync(), enabling full SSRF for SDK embedders
n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. In versions 2.47.4 through 2.47.13, the SDK embedder path (N8NDocumentationMCPServer constructor, getN8nApiClient(), and validateInstanceContext()), the synchronous URL validator in SSRFProtection.validateUrlSync() had no IPv6 checks. IPv4-mapped IPv6 addresses such as http://[::ffff:169.254.169.254] bypassed the cloud-metadata, localhost, and private-IP range checks. An attacker able to supply an n8nApiUrl value could cause the server to issue HTTP requests to cloud metadata endpoints, RFC1918 private networks, or localhost serv
n8n-mcp has unauthenticated session termination and information disclosure in HTTP transport
### Summary
Several HTTP transport endpoints in n8n-mcp lacked proper authentication, and the health check endpoint exposed sensitive operational metadata without credentials.
### Impact
An unauthenticated attacker with network access to the n8n-mcp HTTP server could disrupt active MCP sessions and gather information useful for further attacks.
### Patches
Fixed in **v2.47.6**. All MCP session endpoints now require Bearer authentication. The health check endpoint has been reduced to a minimal liveness response.
### Workarounds
If you cannot upgrade immediately:
- **Restrict network access** to the HTTP server using firewall rules, rev
n8n-MCP has an Authenticated SSRF via instance-URL header in multi-tenant HTTP mode
n8n-MCP is a Model Context Protocol (MCP) server that provides AI assistants with comprehensive access to n8n node documentation, properties, and operations. Prior to 2.47.4, an authenticated Server-Side Request Forgery in n8n-mcp allows a caller holding a valid AUTH_TOKEN to cause the server to issue HTTP requests to arbitrary URLs supplied through multi-tenant HTTP headers. Response bodies are reflected back through JSON-RPC, so an attacker can read the contents of any URL the server can reach — including cloud instance metadata endpoints (AWS IMDS, GCP, Azure, Alibaba, Oracle), internal network services, and any other host the server proce