n8n-mcp

## 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 work

CVE: CVE-2026-55608

## 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/a

CVE: CVE-2026-54052

## 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 U

CVE: CVE-2026-45582

## 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. S

CVE: CVE-2026-45707

## 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 va

### 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

CVE: CVE-2026-44694

### 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

CVE: CVE-2026-42449

### 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 to

CVE: CVE-2026-42282

### 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 itse

CVE: CVE-2026-41495

### 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 acc