n8n-MCP: Path Traversal, Redirect SSRF, and Credentials Leaking Into Telemetry
Three independently-reported vulnerabilities in n8n-MCP before version 2.50.1 gave authenticated callers more access than they were supposed to have. A crafted workflow ID with directory traversal sequences routes outbound requests bearing the n8n API key to arbitrary same-origin endpoints, bypassing DISABLED_TOOLS restrictions entirely. Validated webhook URLs that follow HTTP redirects silently hand responses from internal networks back to the caller. And telemetry uploads containing unredacted workflow diffs carry bearer tokens, API keys, and webhook secrets out of the deployment. All three are fixed in 2.50.1.
What happened
n8n-MCP is the official MCP server for n8n, a widely used workflow automation platform. The server's HTTP mode exposes n8n functionality to AI assistants over the MCP protocol. Three distinct vulnerabilities in versions before 2.50.1 collectively allowed an authenticated MCP caller to read credentials, bypass access controls, and exfiltrate API keys.
The path traversal flaw lives in N8nApiClient. The class interpolates caller-supplied identifiers, including workflowId, credentialId, and tagId, directly into outbound HTTP request path strings without validation. A caller who sends a crafted identifier such as ../../credentials/list causes the underlying HTTP client to normalise the path, landing an n8n-API-key-authenticated request at an endpoint the caller was never supposed to reach. Handler-level restrictions like DISABLED_TOOLS are bypassed entirely because the enforcement happens above the API call.
The redirect SSRF follows from how webhook and trigger URL validation works. The server validates the initial destination against a domain policy. It then follows HTTP 301 and 302 redirects using axios defaults, without re-validating the redirect target. An attacker who controls a redirect server passes initial validation, then redirects the server's request to an internal IP, cloud metadata endpoint (including 169.254.169.254 for AWS IMDS), or any host the process can reach. The response body returns to the caller, making this a non-blind SSRF.
The telemetry leakage is the quietest of the three. Instances running with the default opt-in telemetry upload partial-update operation diffs without redacting sensitive values. Workflow mutations that update node parameters containing bearer tokens, API keys, and webhook secrets send those values in plain text to the telemetry collector.
The PolicyLayer angle
The path traversal bypasses DISABLED_TOOLS, which demonstrates the limit of tool-name allowlisting when the server itself can be tricked into making privileged calls through a different code path. The fix needed is input validation in the API client, not a longer tool blocklist. But from a policy layer perspective, the pattern that catches this class of failure is restricting the network identity the MCP server process uses: if the n8n API key held by n8n-MCP is scoped to read-only workflow data rather than full admin access, the path traversal reaches less-privileged endpoints and the credential list endpoint returns nothing useful.
The redirect SSRF is the most dangerous in cloud environments. The server's egress policy should never permit outbound connections to link-local addresses (169.254.0.0/16) or RFC-1918 ranges from an MCP server process. An egress firewall rule or iptables drop at the host level catches this independent of whether the application validates redirect destinations. Requiring IMDSv2 on AWS eliminates the cloud credential angle even if SSRF is achieved.
The telemetry leakage requires no additional privileges. The control is simple: set N8N_MCP_TELEMETRY_DISABLED=true or run npx n8n-mcp telemetry disable until the upgrade is applied. Any deployment where workflow configurations carry third-party credentials should treat opt-in telemetry as opt-out by default.
Mitigations
Upgrade n8n-MCP to version 2.50.1 or later. If immediate upgrade is not possible: restrict HTTP transport network ACLs so only trusted callers can reach the MCP endpoint; switch to stdio mode for local use cases; disable telemetry immediately via export N8N_MCP_TELEMETRY_DISABLED=true or the npx n8n-mcp telemetry disable command; and apply egress filtering to block outbound connections from the server process to link-local and RFC-1918 addresses.
FAQs
No. Any caller with a valid MCP AUTH_TOKEN can exploit it. The traversal sequences bypass handler-level tool restrictions, so the attack does not require the caller to hold elevated permissions within n8n; the n8n API key belonging to the MCP server process does the privileged work.
Any n8n-MCP deployment before 2.50.1 running with the default opt-in telemetry setting. The leakage happens passively when workflows containing credential-bearing parameters are updated; no attacker-initiated action is required. Disabling telemetry stops the outbound exposure immediately.
Yes, on cloud instances where IMDS is reachable and IMDSv2 is not enforced. The server will follow redirects to 169.254.169.254 and return the metadata response to the caller. AWS IMDSv2, GCP metadata concealment, and equivalent controls on other clouds block this specific escalation path.