GHSA-64xh-79j6-r5v8: n8n: Bypass "Allowed HTTP Request Domains" Credential Restriction in Multiple AI and LLM Nodes

The "Allowed HTTP Request Domains" setting on a credential limits which hosts the credential's secret may be sent to. Admins use it to share a credential, such as an LLM API key, with colleagues who can use it in workflows but not view it. Several AI and LLM nodes skipped that check when the user supplied a base URL or endpoint URL (CWE-863, incorrect authorization). The advisory does not name the nodes.

A low-privileged user who can edit workflows and has use-only access to the shared credential can set the node's endpoint to a server they run. The node then sends the API key to that server. The attacker can read it there and reuse it directly against the real service, outside n8n and its audit trail.

No user interaction is needed. The attack needs an account, and the allowlist must be configured and the credential shared. Instances that never share credentials, or that do not use the allowlist, are not affected. The impact is loss of the shared secret, which can mean spend on the LLM account or access to whatever data it reaches.

Affected: n8n below 2.31.5, and 2.32.0. The advisory lists no separate 1.x fix, so 1.x versions are not marked as patched in this entry.

Check the version:

npm ls n8n

Then list credentials that have "Allowed HTTP Request Domains" set and are shared with users other than their owner. Those are the exposed ones.

Upgrade to n8n 2.31.5 or 2.32.1, or later. For an npm install, run npm install [email protected].

Temporary mitigations from the advisory, none of which fully remove the risk:

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

If you suspect a shared key was sent out, rotate it at the provider after upgrading.

Review workflows that use AI or LLM nodes with a custom base URL or endpoint set, especially ones built by users who only have use access to the credential. Look for endpoints that are not the provider's own host or your approved gateway. Check provider-side usage logs for the shared key being used from unfamiliar IP addresses or at unusual volume, since a stolen key is replayed outside n8n. Review the credential sharing list for unexpected users.

Impact

The credential "Allowed HTTP Request Domains" allowlist was intended to restrict which hosts a credential's secret could be sent to, protecting shared credentials from users who could use but not view them. Several AI/LLM nodes did not enforce this allowlist when a user-supplied base or endpoint URL was set. A low-privileged workflow editor with use-only access to such a shared credential could point one of these nodes at an attacker-controlled host and cause the credential secret to be transmitted there, then reuse it against the underlying service.

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

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 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.