CVE-2026-65593: n8n: Authenticated SSRF via Dynamic Node Parameters Endpoints Allows Internal Network Access

The /rest/dynamic-node-parameters/ endpoints let the editor load options for node fields from a node's upstream API. Two gaps combine. First, the endpoints had no authorization scopes, so any authenticated user could call them, with no need to create or run a workflow. Second, a caller could put an absolute URL in the routing configuration. That replaces the node type's declared baseURL, which is the check meant to keep requests inside the node's own upstream service.

With N8N_SSRF_PROTECTION_ENABLED at its default of false, the n8n server then issues the request to whatever target the caller names. An attacker with a low-privilege account can reach internal services that the n8n host can reach but they cannot, such as admin panels, databases with HTTP interfaces, or cloud metadata endpoints.

The CVSS 4.0 vector scores low impact on n8n itself but high confidentiality impact on subsequent systems (SC:H), which matches an SSRF reaching other services. The attacker needs only an account, so multi-user n8n instances and ones with open sign-up carry the most risk.

The npm package n8n in these ranges: below 1.123.64 on the 1.x line, >= 2.0.0-rc.0, < 2.29.8, and >= 2.30.0, < 2.30.1. Exposure is highest where N8N_SSRF_PROTECTION_ENABLED is unset or false, which is the default, and where several users or untrusted users hold accounts.

Check your version:

npm ls n8n

For Docker installs, check the image tag you run.

Upgrade to n8n 1.123.64, 2.29.8 or 2.30.1, or a later release, whichever matches your release line.

If you cannot upgrade yet, the advisory lists these temporary measures:

• Limit instance access to fully trusted users.
• Set N8N_SSRF_PROTECTION_ENABLED=true to filter private IP ranges and cloud metadata endpoints.
• Restrict network egress from the n8n host so it cannot reach sensitive internal services.

The advisory says none of these fully remove the risk.

The advisory gives no log signature. Review reverse-proxy or n8n access logs for requests to /rest/dynamic-node-parameters/ from accounts that do not build workflows, or from unusual volumes of calls. On the network side, look for outbound requests from the n8n host to internal ranges, link-local metadata addresses, or ports it does not normally use, around those calls. Cloud metadata access logs and internal service logs showing the n8n host as the client are useful too.

Also check which accounts exist on the instance and whether any are unfamiliar.

Impact

Endpoints in /rest/dynamic-node-parameters/ lacked authorization scopes, making it reachable by any authenticated user with no workflow creation or execution required.

By supplying an absolute URL in the routing configuration, a caller could override the node type's declared baseURL, defeating the restriction meant to confine requests to the node's own upstream service. With SSRF protection disabled by default (N8N_SSRF_PROTECTION_ENABLED=false), this let an authenticated user make the n8n server issue HTTP requests to arbitrary internal targets.

Patches

The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.1. Users should upgrade to this version 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.
• Set N8N_SSRF_PROTECTION_ENABLED=true to enable SSRF filtering for private IP ranges and cloud metadata endpoints.
• Restrict network egress from the n8n host to limit reachable internal services.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.