n8n: Bypass "Allowed HTTP Request Domains" Credential Restriction in Multiple AI and LLM Nodes
n8n
- Severity
- High, CVSS 7.1
- CVSS vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N
- Record
- GHSA-64xh-79j6-r5v8
- 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
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.
Description quoted from the GitHub Advisory Database.
Who is affected
n8n is a tool for automating tasks by linking apps and services in workflows. This flaw is in several of its AI building blocks, the parts that connect workflows to AI language model services. It only matters if your organization uses the setting that limits which web addresses a shared saved login (credential) may be sent to, and shares such a credential with users who are not its owner. In that case, a user who can edit workflows and use, but not view, that credential could have its secret sent to a server they control and reuse it with the underlying service. This flaw is rated High.
What to do
- The person who installed or runs n8n for your organization should act. If an IT provider or vendor runs it for you, send them this advisory and ask when the update will be done.
- Upgrade n8n to version
2.31.5or2.32.1, or a later version. - If you cannot upgrade right away, limit who can create and edit workflows to fully trusted users only, and limit credential sharing to fully trusted users only.
- Also check credentials that have web address limits set for any unexpected sharing. These steps only reduce the risk for a short time and do not fully fix it.
Analysis written from the source record as of July 22, 2026 and reviewed before publishing.