GHSA-JXX9-PX88-PJ69

Vulnerability from github – Published: 2026-05-18 17:41 – Updated: 2026-06-09 10:28
VLAI
Summary
n8n-MCP: Multi-tenant MCP requests fall back to process-level n8n credentials when tenant headers are absent or incomplete
Details

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

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

Severity
8.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.51.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "n8n-mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.51.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45707"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T17:41:42Z",
    "nvd_published_at": "2026-05-29T14:16:31Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nWhen `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 \u2014 or supplied only one of them \u2014 silently fell back to the process-level `N8N_API_URL` / `N8N_API_KEY` credentials configured for the operator\u0027s own n8n instance. As a result, an authenticated MCP tenant could cause n8n management calls to execute against the operator\u0027s instance instead of its own.\n\nThis 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.\n\n## Impact\n\nAn authenticated MCP tenant exploiting this path could read and write workflows, executions, data-table contents, and credential metadata on the operator\u0027s n8n instance. If the operator\u0027s n8n permits Code-node execution that reaches OS-level modules, the path could escalate to remote code execution inside the operator\u0027s n8n runtime. The process-level `N8N_API_KEY` is, in practice, a high-privilege key \u2014 Community Edition keys are unscoped by default, and even Enterprise scopes were configured for the operator\u0027s own needs and would carry over wholesale to a tenant who triggered the fallback.\n\n## Patches\n\nFixed in **n8n-mcp 2.51.2**. The fix:\n\n- Rejects header-less multi-tenant requests at the HTTP edge with HTTP 400 / JSON-RPC `-32602` before any handler runs.\n- Refuses to construct an env-credential n8n API client when `ENABLE_MULTI_TENANT=true`.\n- 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\u0027s URL and env-key indicator are not surfaced to tenants.\n\nSingle-tenant behavior is unchanged.\n\n## Upgrade\n\n```bash\n# NPM\nnpx n8n-mcp@latest\n\n# Docker\ndocker pull ghcr.io/czlonkowski/n8n-mcp:latest\n```\n\n## Workarounds\n\nIf an immediate upgrade is not possible, any one of the following reduces or eliminates exposure:\n\n- **Disable multi-tenant mode.** Set `ENABLE_MULTI_TENANT=false` (or unset it) and run a separate n8n-mcp instance per tenant with that tenant\u0027s own `N8N_API_URL` / `N8N_API_KEY`. This removes the affected code path entirely.\n- **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.\n- **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\u0027s `N8N_API_KEY` with the minimum scopes required for the operator\u0027s own n8n-mcp functions. This does not close the boundary break but limits what a falling-back tenant can do.\n\n## Credit\n\nReported by [@u-ktdi](https://github.com/u-ktdi).",
  "id": "GHSA-jxx9-px88-pj69",
  "modified": "2026-06-09T10:28:18Z",
  "published": "2026-05-18T17:41:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/czlonkowski/n8n-mcp/security/advisories/GHSA-jxx9-px88-pj69"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45707"
    },
    {
      "type": "WEB",
      "url": "https://github.com/czlonkowski/n8n-mcp/commit/853015d0897be7cf2d9d4726de195c938e4395ab"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/czlonkowski/n8n-mcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/czlonkowski/n8n-mcp/releases/tag/v2.51.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "n8n-MCP: Multi-tenant MCP requests fall back to process-level n8n credentials when tenant headers are absent or incomplete"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.