GHSA-6qc9-mqvw-jg7x: n8n: Credential Authorization Bypass via Expression in HTTP Request Node `genericAuthType`

n8n checks before execution that a workflow's author may use each credential it references. For the HTTP Request node, the credential type can be given in genericAuthType. If that value is an expression, the check compared the unresolved expression text, not the real credential type. The ownership check was skipped (CWE-863, incorrect authorization). At execution time the expression resolved and the credential was loaded anyway.

The attacker is an authenticated member who can edit a shared workflow. They also need the target credential's identifier, which the advisory says is required. With both, they can make the node send requests authenticated with a credential nobody granted them, or send it to a server they control and so exfiltrate the secret.

The CVSS 4.0 vector shows low privileges, no user interaction, high confidentiality impact, and high impact on subsequent systems. That fits the real risk: credentials commonly unlock other services such as cloud APIs, databases and SaaS accounts. Exposed credential IDs are the limiting factor, and they show up in shared workflows and exports.

Affected: n8n below 1.123.67 on the 1.x line, 2.0.0-rc.0 up to but not including 2.31.5, and 2.32.0. Instances with several users who share workflows are the exposed ones. A single-user instance has no other users' credentials to take.

Check the version:

npm ls n8n

For Docker, check the image tag or the version in the UI.

Upgrade to n8n 1.123.67, 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:

• Restrict instance access to fully trusted users.
• Add n8n-nodes-base.httpRequest to NODES_EXCLUDE if you do not need the HTTP Request node.
• Audit credential sharing and workflow access to limit who can see credential IDs.

After upgrading, rotate credentials that untrusted members could have reached.

Search workflows for HTTP Request nodes where genericAuthType holds an expression, such as one starting with ={{, rather than a fixed type. Compare each such node's credential reference with the workflow owner's own credentials. Flag any workflow that references a credential ID owned by someone else. Check the target service's logs for requests made with the credential from n8n workflows you do not recognise.

Impact

An authenticated member with edit access to a shared workflow could reference another user's credential in an HTTP Request node while specifying the credential type through an expression. Because the pre-execution permission check compared the unresolved expression instead of the real credential type, the ownership check was skipped and the credential was loaded at execution time, letting the member use or exfiltrate a credential they were never granted. Exploitation required knowing the target credential's identifier.

Patches

The issue has been fixed in n8n versions 1.123.67, 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.
• Exclude the HTTP Request node by adding n8n-nodes-base.httpRequest to the NODES_EXCLUDE environment variable, if the node is not required.
• Audit credential sharing and workflow access to limit exposure of credential IDs to untrusted users.

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