n8n: Credential Authorization Bypass via Expression in HTTP Request Node `genericAuthType`
n8n
- Severity
- High, CVSS 7.1
- CVSS vector
- CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N
- Record
- GHSA-6qc9-mqvw-jg7x
- Affects
- n8n
- Known exploited
- Not listed in the CISA Known Exploited Vulnerabilities catalog
- Published
- Record first published by the source
- July 22, 2026
- Source last modified
- July 22, 2026
Description
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.
Description quoted from the GitHub Advisory Database.
Who is affected
n8n, a tool for connecting different apps and automating routine tasks, has a flaw in the building block that lets a workflow send web requests to other services. A signed-in user who can edit a shared workflow could use another person's saved login details, such as a password or access key, even though they were never given access to them. That user could also copy those details out. To do this, the user must know the identifier of that saved login. This flaw affects n8n versions that do not include the fix released in 1.123.67, 2.31.5 and 2.32.1. This flaw is rated High.
What to do
- The person who installed or runs n8n for your organization, or the IT provider or vendor who manages it, should act on this. If someone outside your organization runs it for you, send them this advisory and ask when the update will be done.
- Update n8n to version
1.123.67,2.31.5or2.32.1, or a later version. - If you cannot update right away, limit access to n8n to fully trusted users only.
- If your workflows do not need the web request building block, turn it off by adding it to the
NODES_EXCLUDEsetting, as shown in the vendor advisory linked on this page. - Review who has access to shared workflows and saved logins, so fewer people can see their identifiers. These short-term steps reduce the risk but do not remove it.
Analysis written from the source record as of July 22, 2026 and reviewed before publishing.