Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
11 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In multi-tenant HTTP mode (ENABLEMULTITENANT=true), an authenticated tenant could, under certain conditions, reach n8n-mcp's local default-scope workflowversions 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…
Recommended action: Upgrade to 2.57.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 (ENABLEMULTITENANT=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…
Recommended action: Upgrade to 2.56.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When ENABLEMULTITENANT=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 N8NAPIURL / N8NAPIKEY 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 (ENABLEMULTITENANT 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.…
Recommended action: Upgrade to 2.51.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.51.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 DISABLEDTOOLS). 2. Validated webhook, form, and chat trigger URLs followed redirects. A URL that passed initial validation could redirect the outbound request to a host that would otherwise have been rejected, with the response body returned to the caller. Reachable as non-blind SSRF over authenticated MCP calls. 3. Mutation telemetry stored unredacted operation payloads. On instances running with the default opt-in telemetry, partial-update operation diffs were uploaded without redaction. Operation values can carry the same…
Recommended action: Upgrade to 2.50.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Authenticated Server-Side Request Forgery affecting the webhook trigger tools, the n8n API client (N8NAPIURL), 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 AUTHTOKEN: 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…
Recommended action: Upgrade to 2.50.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 2.47.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 n8nmanagecredentials.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 n8nmanagecredentials - 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 (AUTHTOKEN 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…
Recommended action: Upgrade to 2.47.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 (MCPMODE=http). The stdio transport is not affected. Patched v2.47.11 and…
Recommended action: Upgrade to 2.47.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, reverse proxy IP allowlists, or a VPN so that only trusted clients can reach it. - Use stdio mode (MCPMODE=stdio) instead of HTTP mode. The stdio transport does not expose any HTTP endpoints and is unaffected by this vulnerability. Upgrading to v2.47.6 is still strongly recommended. Credit Reported by @yotampe-pluto.
Recommended action: Upgrade to 2.47.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An authenticated Server-Side Request Forgery in n8n-mcp allows a caller holding a valid AUTHTOKEN 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 AUTHTOKEN, 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…
Recommended action: Upgrade to 2.47.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.