TL;DR: n8n-mcp disclosed three CVEs in 2026: an SSRF (CVE-2026-39974), credentials written to logs before redaction (CVE-2026-42282), and a CVSS 9.9 cross-tenant IDOR letting any authenticated tenant read another tenant's workflow credentials. All three require HTTP transport with multi-tenant headers. Run it locally over stdio and none of them apply.
One decision produced all three#
Read the three advisories together and a pattern falls out immediately: every one of them lives in code that only exists because the server can serve more than one caller.
CVE-2026-39974 is server-side request forgery. An authenticated caller holding a valid AUTH_TOKEN can make the server issue HTTP requests to arbitrary URLs supplied through multi-tenant headers. Fixed in 2.47.4.
CVE-2026-42282 is information disclosure. In HTTP transport mode before 2.47.13, the request dispatcher wrote full tools/call arguments and JSON-RPC params into server logs before any redaction ran. The fix added a helper that summarises tool-call arguments instead of dumping them.
CVE-2026-54052 is the serious one, scored 9.9. An insecure direct object reference let any authenticated tenant read another tenant's workflow credentials or wipe their backups.
Multi-tenant headers. Per-tenant scoping. HTTP request dispatch. None of that code path runs when the server is launched over stdio by a single operator on their own laptop, which is how the majority of MCP servers are actually deployed and, evidently, how this one was designed to be.
The same package, two deployment modes, and a completely different exposure. None of the three CVEs reach a local stdio deployment.
Why the logging bug is worse than its rating#
Information disclosure into your own logs sounds like a compliance finding rather than a breach. For this server it is neither, because of what passes through the arguments.
n8n-mcp brokers workflow credentials. Tool arguments routed to credential management carry bearer tokens, OAuth client secrets, and per-tenant API keys, and any tool invocation can embed webhook authentication headers. Those are the arguments that were being written verbatim before redaction.
A secret in a log is not a secret in one place. Logs ship to aggregation platforms, get retained for months under policies written for debugging rather than secret handling, and are readable by on-call engineers, SIEM pipelines, and increasingly by AI assistants pointed at the log store. The credential store has an access policy. The log platform has a different, much broader one. Writing a secret into the second is a quiet migration from the first.
This is the same failure of channel discipline we documented in our research on MCP error hypnosis, where sensitive data was correctly identified and then correctly sanitised in the wrong channel. Redaction that runs after the write is not redaction.
The tenancy assumption nobody wrote down#
The deeper issue is that MCP servers are overwhelmingly built for a trust model with exactly one principal. The operator, the user, and the credential holder are the same person, sitting at the same machine. Under that assumption, "any authenticated caller can reach any object" is not a bug, because there is only one caller.
Put that same code behind HTTP and hand tokens to several teams and the assumption silently inverts. Every object lookup that never needed a tenant check now needs one, and nothing in the protocol tells you which ones you missed. CVE-2026-54052 is what that looks like when it reaches production: not an exotic exploit, just an object reference that was never scoped because it never had to be.
We have made this argument about MCP security generally, and it is the same structural point behind name-keyed trust in Claude Code. The protocol defines how messages are shaped, not who is allowed to ask for what. That second question is left entirely to implementations, and implementations written for a single user answer it by not asking.
Do not confuse n8n-mcp with n8n#
These are separate codebases with separate advisories, and teams patch the wrong one routinely.
n8n is the workflow automation platform. n8n-mcp is the MCP server that exposes it to agents. The platform has had its own serious issues in the same period, including critical flaws allowing remote code execution and exposure of stored credentials. Upgrading n8n does nothing for n8n-mcp, and upgrading n8n-mcp does nothing for n8n. Check both version numbers separately.
Deployment guidance#
Prefer stdio, locally. This removes the multi-tenant header handling that two of the three CVEs depend on, and it is the mode the server was designed around. Most teams reach for HTTP because it is convenient to centralise, not because they need it.
If you run HTTP, pin at or above 2.47.13. That covers all three disclosed issues. Pin the version rather than tracking a floating tag.
Put an authenticating proxy in front. Do not expose the server directly. The SSRF and the IDOR both begin from "authenticated caller", so the value of that credential is worth protecting properly.
Restrict egress. An SSRF is only as useful as what the server can reach. Deny-by-default outbound rules turn CVE-2026-39974 from a pivot into an error message.
Audit your log pipeline. Confirm that tool-call arguments are not being captured, and if you ran a version before 2.47.13 in HTTP mode, treat every credential that passed through it as exposed and rotate it. The patch stops future writes; it does not unwrite your retained logs.
FAQ#
Is the n8n MCP server safe to use?#
In local stdio mode, on one machine, for one user, its exposure is modest. In HTTP transport with multiple tenants, it accumulated three separate CVEs in a single release cycle, including CVE-2026-54052, a CVSS 9.9 cross-tenant credential theft. The transport and tenancy decision, not the package itself, is what determines your risk. Run it locally and single-tenant unless you have a specific reason not to.
What CVEs affect n8n-mcp?#
Three disclosed in 2026. CVE-2026-39974 is a server-side request forgery in which an authenticated caller can make the server issue HTTP requests to arbitrary URLs supplied through multi-tenant headers, fixed in 2.47.4. CVE-2026-42282 is an information disclosure where full tool-call arguments were written to server logs before redaction in HTTP transport mode, fixed in 2.47.13. CVE-2026-54052 is an insecure direct object reference scored 9.9 that let any authenticated tenant read another tenant's workflow credentials or delete their backups.
Why is a credential-logging bug serious if the logs are internal?#
Because of what n8n-mcp handles. Tool arguments routed to credential management can carry bearer tokens, OAuth client secrets, and per-tenant API keys, and any tool call can embed webhook authentication headers. Logs get shipped to aggregation platforms, retained for months, and read by people and systems with far broader access than the credential store itself. A secret written to a log has effectively been copied to every downstream consumer of that log.
Is n8n-mcp the same thing as n8n?#
No, and conflating them will misdirect your patching. n8n is the workflow automation platform. n8n-mcp is an MCP server that exposes n8n to AI agents. They are separate codebases with separate advisories and separate version numbers, and n8n itself has had its own critical issues in the same period. Patching one does nothing for the other.
How should I deploy n8n-mcp safely?#
Prefer stdio transport on the operator's own machine, which removes the multi-tenant header handling that two of the three CVEs depend on. If you must run HTTP, pin a version at or above 2.47.13, terminate it behind an authenticating proxy rather than exposing it directly, restrict egress so an SSRF has nowhere useful to reach, and confirm your log pipeline is not capturing tool arguments.
What does the pattern across these three CVEs tell you?#
That the security model changed when the transport did. Each flaw lives in code that only matters once the server serves more than one caller: multi-tenant headers, per-tenant scoping, request dispatch logging. A design that is reasonable for a single local operator becomes a shared credential broker the moment it is put behind HTTP, and the code was not originally written for that job.
Find every instance, and how it is deployed#
Whether a deployment is stdio or HTTP multi-tenant is the difference between none of these CVEs applying and all three, and that answer lives on individual machines rather than in one central config. Workstation Lens inventories the MCP servers running across your fleet, inspects how each one is launched, and flags the versions carrying known advisories.
