Threat Intelligence Database

## Summary In multi-tenant HTTP mode (`ENABLE_MULTI_TENANT=true`), an authenticated tenant could, under certain conditions, reach n8n-mcp's local default-scope `workflow_versions` backups instead of being confined to its own tenant scope. This affects n8n-mcp's own local workflow-version storage, not a normal n8n API capability. ## Impact An authenticated MCP HTTP tenant could read or delete workflow-version backups stored in the default (single-tenant) scope — for example backups left from a prior single-tenant deployment or a migration period. Workflow snapshots may contain sensitive workflow configuration depending on their contents. Single-tenant and stdio deployments are not affected. ## Affected versions `<= 2.57.3` ## Patched version `2.57.4` ## Remediation Upgrade to n8n-mcp `2.57.4` or later. The fix requires a complete tenant context in multi-tenant mode and fails closed for workflow-version access that cannot be attributed to a specific tenant. ## Workarounds - Restrict network access to the HTTP endpoint (firewall / reverse proxy / VPN) so only trusted callers can reach it. - Run in stdio mode, which has no multi-tenant HTTP surface. - If default-scope backups from a prior single-tenant deployment are not needed, removing them eliminates the exposure. ## Credit Reported by @DavidCarliez.

## Impact In multi-tenant HTTP deployments — where a single n8n-mcp server serves several tenants — the locally stored workflow version history (the automatic backups taken before workflow updates) was not isolated per tenant. An authenticated tenant could read workflow version snapshots belonging to other tenants, and could delete or destroy other tenants' stored backups. A stored snapshot includes full node definitions, so the exposed data can contain credential references and authorization headers configured on nodes. This is therefore a confidentiality issue in addition to an integrity/availability one. ## Affected configurations - HTTP mode with multi-tenancy enabled (`ENABLE_MULTI_TENANT=true`), where multiple tenants are served by a single shared instance and database. Not affected: - stdio / single-user deployments (e.g. Claude Desktop). - Single-tenant HTTP deployments (one tenant per instance and database). ## Affected versions `<= 2.56.0` ## Patched version `2.56.1`. The stored version history is now isolated per instance, so a tenant can only access its own backups. Upgrading runs a one-time migration that isolates existing history and clears previously stored, un-scoped backups (these are auto-created, short-retention backups). ## Workarounds If users cannot upgrade immediately: - Disable the workflow version tool by setting `DISABLED_TOOLS=n8n_workflow_versions` in the server environment (for example, in your Docker `.env`). This removes the affected tool from the deployment for all tenants; automatic backups are unaffected, but the cross-tenant access path is closed. - Alternatively, do not run in multi-tenant mode — serve each tenant from a separate instance with its own database, so no local store is shared between tenants. - Restrict network access to the HTTP endpoint to trusted operators. stdio and single-tenant HTTP deployments are not affected. ## Credit Reported by Francisco Rosales (@0xmagic0) and coordinated by Ax Sharma (@axsharma) of Manifold Security.

## Summary 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` that are run as a shared multi-tenant service. Single-tenant deployments (`ENABLE_MULTI_TENANT` unset or `false`) are not affected. ## Impact An authenticated MCP tenant exploiting this path could read and write workflows, executions, data-table contents, and credential metadata on the operator's n8n instance. If the operator's n8n permits Code-node execution that reaches OS-level modules, the path could escalate to remote code execution inside the operator's n8n runtime. The process-level `N8N_API_KEY` is, in practice, a high-privilege key — Community Edition keys are unscoped by default, and even Enterprise scopes were configured for the operator's own needs and would carry over wholesale to a tenant who triggered the fallback. ## Patches Fixed in **n8n-mcp 2.51.2**. The fix: - Rejects header-less multi-tenant requests at the HTTP edge with HTTP 400 / JSON-RPC `-32602` before any handler runs. - Refuses to construct an env-credential n8n API client when `ENABLE_MULTI_TENANT=true`. - Closes secondary leak paths in trigger handlers and in the responses of `n8n_health_check`, `n8n_diagnostic`, `n8n_deploy_template`, and `n8n_audit_instance` so the operator's URL and env-key indicator are not surfaced to tenants. Single-tenant behavior is unchanged. ## Upgrade ```bash # NPM npx n8n-mcp@latest # Docker docker pull ghcr.io/czlonkowski/n8n-mcp:latest ``` ## Workarounds If an immediate upgrade is not possible, any one of the following reduces or eliminates exposure: - **Disable multi-tenant mode.** Set `ENABLE_MULTI_TENANT=false` (or unset it) and run a separate n8n-mcp instance per tenant with that tenant's own `N8N_API_URL` / `N8N_API_KEY`. This removes the affected code path entirely. - **Reject malformed requests at a proxy.** Require both `x-n8n-url` and `x-n8n-key` headers on every request and return 400 if either is missing. Neutralizes the primary header-omission path but does not address the secondary response-shape disclosures, so this is a partial mitigation only. - **Reduce the blast radius of the operator API key.** If your n8n instance supports API key scoping (Enterprise, or a Community Edition build that exposes scopes), provision the operator's `N8N_API_KEY` with the minimum scopes required for the operator's own n8n-mcp functions. This does not close the boundary break but limits what a falling-back tenant can do. ## Credit Reported by [@u-ktdi](https://github.com/u-ktdi).

## Summary In affected versions of n8n-mcp, 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`. ## Impact Operators with access to the project's telemetry backend could read partial fragments of workflow URL parameters that should not have been collected. The bug was scoped to URL-shaped fields in workflow *definitions*; credentials, OAuth tokens, and workflow *execution* data are not affected — credentials are removed by a separate code path, and long secrets and known-provider tokens are matched by dedicated patterns. ## Patches Fixed in **n8n-mcp `2.51.3`**. Upgrading is the recommended remediation. ## Workarounds For users who cannot upgrade immediately, disable anonymous telemetry by setting any of these environment variables to `true`: - `N8N_MCP_TELEMETRY_DISABLED` - `TELEMETRY_DISABLED` - `DISABLE_TELEMETRY` ## Credit Reported by @u-ktdi.

### Summary Authenticated Server-Side Request Forgery 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. ### Impact A caller with access to the MCP session can drive HTTP requests from the n8n-mcp host to internal services and cloud metadata endpoints that the SSRF gate is meant to block. The response body is returned to the caller, making internal-service enumeration and credential theft immediate without any out-of-band channel. - **Multi-tenant HTTP deployments** where tenants share an `AUTH_TOKEN`: any tenant with valid credentials can reach the operator's cloud metadata service and exfiltrate temporary IAM / GCP service account / Azure managed-identity credentials. - **Single-tenant deployments**: indirect prompt injection through tool arguments reaches the same surface; an attacker who can influence the LLM's tool calls can read internal services from the n8n-mcp host. - **Stdio deployments** are reachable via the same prompt-injection path. ### Patched Versions Fixed in `[email protected]`. **Note for operators:** The same SSRF gate that previously covered webhook URLs now also covers the n8n API client base URL. If `N8N_API_URL` points at `http://localhost:5678` (n8n on the same host) or an RFC1918 address (n8n on the same private network), set `WEBHOOK_SECURITY_MODE=moderate` (allows localhost, still blocks RFC1918 and cloud metadata) or `WEBHOOK_SECURITY_MODE=permissive` (allows RFC1918 too — only safe on a trusted private network). Default `strict` is correct for deployments where n8n is reachable at a public hostname. ### Workarounds For deployments that cannot upgrade immediately: 1. **Restrict network egress** from the n8n-mcp host with a firewall, reverse proxy, or cloud security group. Explicitly deny cloud metadata IPs (`169.254.169.254`, `169.254.170.2`, `100.100.100.200`, `192.0.0.192`, and the GCP `metadata.google.internal` resolved IP) and any RFC1918 networks the server does not legitimately need to reach. 2. **Run in stdio mode** instead of HTTP if the multi-tenant surface is not needed (no shared `AUTH_TOKEN` to compromise). 3. **Disable workflow management tools** via `DISABLED_TOOLS=n8n_trigger_webhook_workflow,n8n_create_workflow,n8n_test_workflow` if the deployment does not need them. ### Credit Reported by [@fg0x0](https://github.com/fg0x0).

### Impact 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 pipelines, support/ops access), this can result in disclosure of: - bearer tokens and OAuth credentials sent through `n8n_manage_credentials` - per-tenant API keys and webhook auth headers embedded in tool arguments - arbitrary secret-bearing payloads passed to any MCP tool The issue requires authentication (`AUTH_TOKEN` accepted by the server), so unauthenticated callers cannot trigger it; the runtime exposure is also reduced by an existing console-silencing layer in HTTP mode, but that layer is fragile and the values are still constructed and passed into the logger. The fix removes the leak at the source. Impact category: **CWE-532** (Insertion of Sensitive Information into Log File). CVSS 3.1 score: **4.3 Medium** (`AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N`). ### Affected Deployments running n8n-mcp **v2.47.12 or earlier** in HTTP transport mode (`MCP_MODE=http`). The stdio transport short-circuits the relevant log calls and is not affected in practice. ### Patched **v2.47.13** and later. - npm: `npx n8n-mcp@latest` (or pin to `>= 2.47.13`) - Docker: `docker pull ghcr.io/czlonkowski/n8n-mcp:latest` The patch routes tool-call arguments through a metadata-only summarizer (`summarizeToolCallArgs`) that records type, top-level key names, and approximate size — never values. The same pattern was adopted earlier for HTTP request bodies in GHSA-pfm2-2mhg-8wpx. ### Workarounds If developers cannot upgrade immediately: - Restrict access to the HTTP port (firewall, reverse proxy, or VPN) so only trusted clients can authenticate. - Restrict access to server logs (no shared SIEM ingestion, no support read-only access) until the upgrade lands. - Switch to stdio transport (`MCP_MODE=stdio`, the default for CLI invocation), which has no HTTP surface and short-circuits the affected log calls. ### Credit n8n-MCP thanks [@Mirr2](https://github.com/Mirr2) (Organization / Jormungandr) for reporting this issue.

### Impact 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-RPC request payloads sent to the MCP endpoint Access control itself was not bypassed — unauthenticated requests were correctly rejected with `401 Unauthorized` — but sensitive values from those rejected requests could still be persisted in logs. Impact category: **CWE-532** (Insertion of Sensitive Information into Log File). ### Affected Deployments running n8n-mcp **v2.47.10 or earlier** in HTTP transport mode (`MCP_MODE=http`). The stdio transport is not affected. ### Patched **v2.47.11** and later. - npm: `npx n8n-mcp@latest` (or pin to `>= 2.47.11`) - Docker: `docker pull ghcr.io/czlonkowski/n8n-mcp:latest` ### Workarounds If users cannot upgrade immediately: - Restrict network access to the HTTP port (firewall, reverse proxy, or VPN) so only trusted clients can reach the endpoint. - Switch to stdio transport (`MCP_MODE=stdio`, the default for CLI invocation), which has no HTTP surface. ### Credit n8n-MCP thanks [@S4nso](https://github.com/S4nso) (Organization / Jormungandr) for reporting this issue.

### Impact In 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 (AWS IMDS, GCP, Azure, Alibaba, Oracle), RFC1918 private networks, or localhost services. Response bodies are returned to the caller (non-blind SSRF), and the `n8nApiKey` is forwarded in the `x-n8n-api-key` header to the attacker-controlled target. The first-party HTTP server deployment was not primarily affected — it has a second async validator (`validateWebhookUrl`) that catches IPv6 addresses. Impact category: **CWE-918** (Server-Side Request Forgery). ### Affected Deployments embedding n8n-mcp as an SDK using `N8NDocumentationMCPServer` or `N8NMCPEngine` with user-supplied `InstanceContext` on versions **v2.47.4 through v2.47.13**. ### Patched **v2.47.14** and later. - npm: `npx n8n-mcp@latest` (or pin to `>= 2.47.14`) - Docker: `docker pull ghcr.io/czlonkowski/n8n-mcp:latest` ### Workarounds If developers cannot upgrade immediately: - **Validate URLs before passing to the SDK** — reject any `n8nApiUrl` whose hostname is an IP literal (bracketed IPv6 or dotted IPv4) before calling `N8NDocumentationMCPServer` / `getN8nApiClient()`. Accept only URLs with DNS-resolvable hostnames. - **Restrict egress at the network layer** — block outbound traffic from the n8n-mcp process to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local `169.254.0.0/16`, and cloud metadata endpoints. Defense-in-depth against this class of issue and recommended even after upgrading. - **Do not accept user-controlled `n8nApiUrl` values** — if the project's integration derives the URL from internal configuration only, this vulnerability is not reachable. Upgrading to v2.47.14 is still strongly recommended. ### Credit Reported by @manthanghasadiya.

## Impact 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 process has network access to. The primary at-risk deployments are multi-tenant HTTP installations where more than one operator can present a valid `AUTH_TOKEN`, or where a token is shared with less-trusted clients. Single-tenant stdio deployments and HTTP deployments without multi-tenant headers are not affected. ## Affected versions `n8n-mcp` ≤ `2.47.3` (all versions up to and including 2.47.3). ## Patched versions `n8n-mcp` `2.47.4` and later. ## Workarounds If you cannot immediately upgrade: 1. **Egress filtering at the network layer** — block outbound traffic from the `n8n-mcp` container to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local `169.254.0.0/16`, and any other internal ranges. This defends against any future SSRF-class issue and is recommended even after upgrading. 2. **Disable multi-tenant headers** — if your deployment does not require per-request instance switching, unset `ENABLE_MULTI_TENANT` and do not accept `x-n8n-url` / `x-n8n-key` headers at the reverse proxy. 3. **Restrict `AUTH_TOKEN` distribution** — ensure the bearer token is only held by fully trusted operators until you can upgrade. ## Remediation Upgrade to `n8n-mcp` 2.47.4 or later. No configuration changes are required; the fix adds validation at the URL entry points and normalizes URLs at the API client layer. ## Credits Reported by the Eresus Security Research Team. @ibrahmsql