CVE-2026-65596: n8n: GraphQL Node Bypasses "Allowed HTTP Request Domains" Restriction

n8n lets an admin lock an HTTP-based credential to certain hosts with "Allowed HTTP Request Domains". The HTTP Request node enforces that list. The GraphQL node did not. It sent the credential to whatever endpoint the workflow named.

So a user who can build workflows and can use a shared credential, but is not meant to see or move its secret, could add a GraphQL node, set the endpoint to a server they control, and select the credential. When the node runs, n8n attaches the header, basic-auth pair, query parameter or OAuth token and sends it to the attacker's server. The attacker reads the secret from their own request logs.

The flaw only matters where a credential has domain restrictions set and non-owner users can use it. In that setup the restriction was the control that kept the secret away from those users, and the GraphQL node removed it. The leaked secret may open other systems, which is why the CVSS vector rates impact on subsequent systems as high. The CWE is incorrect authorization (CWE-863).

The npm package n8n below 1.123.64 on the 1.x line, from 2.0.0 up to below 2.29.8, and 2.30.0. Only instances where at least one credential uses "Allowed HTTP Request Domains" and is usable by users other than its owner are affected.

npm ls n8n

Then review credentials that have domain restrictions and who each is shared with.

Upgrade n8n to 1.123.64, 2.29.8 or 2.30.1, or later, matching your release line.

The advisory's temporary measures, which it says do not fully remove the risk:

• Limit workflow creation and editing to fully trusted users.
• Limit credential sharing to fully trusted users.
• Audit credentials with domain restrictions for unexpected sharing.

If a restricted credential was shared with users you do not fully trust, rotate its secret after upgrading.

Search workflows for GraphQL nodes whose endpoint is outside the credential's allowed domains. Check workflow edit history and execution logs for GraphQL nodes added by non-owner users that use a credential with domain restrictions. Check the egress logs of the n8n host for requests from GraphQL node executions to unfamiliar hosts.

On the credential's own service, look for use of the secret from addresses that are not n8n. If a credential may have leaked, treat it as exposed and rotate it.

Impact

The GraphQL node did not enforce the "Allowed HTTP Request Domains" restriction on HTTP-based credentials (such as Header Auth, Basic Auth, Query Auth, and OAuth), unlike the HTTP Request node. An authenticated user able to create or edit workflows could therefore point the node's endpoint at a server they control and exfiltrate restricted credentials.

Only instances where a credential has "Allowed HTTP Request Domains" configured and is usable by non-owner users are affected.

Patches

The issue has been fixed in n8n versions 1.123.64, 2.29.8, and 2.30.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 workflow creation and editing permissions to fully trusted users only.
• Restrict credential sharing to fully trusted users only.
• Audit credentials with domain restrictions for unexpected sharing relationships.

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