AI Threat Alert
The n8n MCP Client node — used to connect n8n's AI agent workflows to external Model Context Protocol servers — forwarded user-supplied endpoint URLs directly instead of routing them through n8n's built-in SSRF protection, letting the request reach and read back responses from internal or otherwise blocked hosts. Any authenticated user with permission to create or edit a workflow could weaponize this to pivot from the n8n server into internal network segments, cloud metadata endpoints, or admin interfaces the SSRF guardrail was specifically meant to block — a meaningful blast radius given n8n has 16 downstream dependents and a mediocre 6.6/10 OpenSSF Scorecard reflecting broader supply-chain hygiene gaps in the project. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template, so this reads as a low-noise, insider-facing bug rather than an actively exploited internet-facing flaw. Patch to n8n 2.31.5 or 2.32.1+ immediately; if that's not possible short-term, restrict workflow-edit access to trusted users, add the MCP Client node to NODES_EXCLUDE, or block egress from the n8n host to internal/link-local ranges at the network layer.
What is the risk?
Rated medium and consistent with that: exploitation requires an authenticated account with workflow create/edit rights, so it is not remotely exploitable by an anonymous internet attacker. However, n8n instances are frequently shared across teams with varying trust levels, and the whole point of the bypassed control was to stop exactly this kind of internal pivot — so the effective risk is materially higher in multi-tenant or loosely-governed n8n deployments, especially those running in cloud environments where SSRF can reach instance metadata services and yield cloud credentials. No public exploit code or scanner template exists, and it is not in CISA KEV, so opportunistic mass exploitation is unlikely; the realistic threat is a malicious or compromised insider.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | >= 2.32.0, < 2.32.1 | 2.32.1 |
Do you use n8n? You're affected.
How severe is it?
What should I do?
1 step-
Upgrade to n8n 2.31.5 or 2.32.1 or later immediately — this fully closes the bypass. If upgrading isn't immediately possible: (1) restrict n8n instance access to fully trusted users only, since exploitation requires workflow edit rights; (2) disable the MCP Client node entirely by adding it to the NODES_EXCLUDE environment variable; (3) restrict network egress from the n8n host at the firewall/network layer to block internal RFC1918 ranges and link-local addresses (especially 169.254.169.254 cloud metadata). For detection, audit workflow definitions and edit history for MCP Client nodes pointing at internal-looking hostnames or IPs, and monitor outbound connections from the n8n host for unexpected internal destinations.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-vhf8-cg2h-cg3p?
The n8n MCP Client node — used to connect n8n's AI agent workflows to external Model Context Protocol servers — forwarded user-supplied endpoint URLs directly instead of routing them through n8n's built-in SSRF protection, letting the request reach and read back responses from internal or otherwise blocked hosts. Any authenticated user with permission to create or edit a workflow could weaponize this to pivot from the n8n server into internal network segments, cloud metadata endpoints, or admin interfaces the SSRF guardrail was specifically meant to block — a meaningful blast radius given n8n has 16 downstream dependents and a mediocre 6.6/10 OpenSSF Scorecard reflecting broader supply-chain hygiene gaps in the project. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template, so this reads as a low-noise, insider-facing bug rather than an actively exploited internet-facing flaw. Patch to n8n 2.31.5 or 2.32.1+ immediately; if that's not possible short-term, restrict workflow-edit access to trusted users, add the MCP Client node to NODES_EXCLUDE, or block egress from the n8n host to internal/link-local ranges at the network layer.
Is GHSA-vhf8-cg2h-cg3p actively exploited?
No confirmed active exploitation of GHSA-vhf8-cg2h-cg3p has been reported, but organizations should still patch proactively.
How to fix GHSA-vhf8-cg2h-cg3p?
Upgrade to n8n 2.31.5 or 2.32.1 or later immediately — this fully closes the bypass. If upgrading isn't immediately possible: (1) restrict n8n instance access to fully trusted users only, since exploitation requires workflow edit rights; (2) disable the MCP Client node entirely by adding it to the NODES_EXCLUDE environment variable; (3) restrict network egress from the n8n host at the firewall/network layer to block internal RFC1918 ranges and link-local addresses (especially 169.254.169.254 cloud metadata). For detection, audit workflow definitions and edit history for MCP Client nodes pointing at internal-looking hostnames or IPs, and monitor outbound connections from the n8n host for unexpected internal destinations.
What systems are affected by GHSA-vhf8-cg2h-cg3p?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP tool integrations, workflow automation pipelines.
What is the CVSS score for GHSA-vhf8-cg2h-cg3p?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0053 AI Agent Tool Invocation AML.T0075 Cloud Service Discovery AML.T0086 Exfiltration via AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
## Impact On an n8n instance with SSRF protection enabled, the MCP Client node sent requests to a user-supplied endpoint without routing them through that protection and without pinning the resolved address. An authenticated user who could create or edit a workflow could therefore cause the server to connect to internal or otherwise blocked hosts and read the responses back through the workflow, exposing internal services the SSRF protection was meant to protect. ## Patches The issue has been fixed in n8n versions 2.31.5 and 2.32.1. Users should upgrade to one of these versions or later to remediate the vulnerability. ## Workarounds If upgrading is not immediately possible, administrators should consider the following temporary mitigations: - Restrict n8n instance access to fully trusted users only. - Disable the MCP Client node by adding it to the `NODES_EXCLUDE` environment variable. - Restrict network egress from the n8n host to block access to internal and link-local address ranges at the network level. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.
Exploitation Scenario
An authenticated n8n user with workflow-edit rights — for example a lower-privilege team member who can build automations but isn't meant to reach internal infrastructure — adds or edits a workflow containing an MCP Client node and points its endpoint at an internal target normally blocked by n8n's SSRF protection, such as the cloud provider's instance metadata endpoint or an internal admin dashboard not exposed to the internet. Because the MCP Client node skips the SSRF pinning/protection path, the n8n server itself issues the outbound request, and the response is returned into the workflow execution where the attacker can view it directly in the n8n UI — using n8n as an internal reconnaissance and data-exfiltration proxy without ever needing network-level access themselves.
Weaknesses (CWE)
CWE-918 — Server-Side Request Forgery (SSRF): The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2026-33663 10.0 n8n: member role steals plaintext HTTP credentials
Same package: n8n CVE-2026-33660 10.0 TensorFlow: type confusion NPD in tensor conversion
Same package: n8n CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same package: n8n CVE-2026-27495 9.9 n8n: Code Injection enables RCE
Same package: n8n CVE-2026-27577 9.9 n8n: Code Injection enables RCE
Same package: n8n