GHSA-vhf8-cg2h-cg3p: n8n: SSRF Protection Bypass via MCP Client Node

n8n's SSRF protection filters outbound requests to private ranges and metadata addresses, and pins the resolved IP address so a hostname cannot be switched to a blocked address after the check. The MCP Client node connects to an MCP server at a URL the workflow author sets. Before the fix it did this without going through that protection and without pinning the resolved address.

So an admin who had turned SSRF protection on, and relied on it, still had a gap. A user with workflow edit rights could add an MCP Client node, point its endpoint at an internal service or a link-local address such as a cloud metadata endpoint, and run the workflow. The server makes the connection, and the workflow can pass the response back to the user. Internal services the protection was meant to shield become readable.

The fix commit for the 2.32.x line adds a lookup function that pins the resolved address at connection time for outbound agents. That matches the missing pinning described in the advisory.

The attacker needs only a low-privilege account that can edit workflows. The CVSS vector rates impact on subsequent systems, the internal services, as high.

The npm package n8n below 2.31.5, and 2.32.0. The advisory lists no 1.x range. Instances that enable SSRF protection are the ones the advisory describes. Instances without it already allowed such requests by default, so they have the same exposure through other nodes.

npm ls n8n

To see who is at risk, list the accounts that can create or edit workflows, and check whether any workflow uses an MCP Client node.

Upgrade n8n to 2.31.5 or 2.32.1, or later.

Temporary measures from the advisory, which it says do not fully remove the risk:

• Limit instance access to fully trusted users.
• Turn off the MCP Client node by adding it to the NODES_EXCLUDE environment variable.
• Block access to internal and link-local address ranges at the network level, by restricting egress from the n8n host.

The network rule is the most reliable of the three, since it does not depend on n8n's own checks.

Search workflows for MCP Client nodes whose endpoint URL points at private IP ranges, localhost, link-local addresses such as the cloud metadata address, or internal hostnames. Check the history of recently created or edited workflows by non-admin users. In network or firewall logs, look for connections from the n8n host to internal services that it does not normally call, at the times those workflows ran.

Cloud metadata service logs and internal service access logs that show the n8n host as the client are useful too.

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.