AI Threat Alert
## 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...
Full CISO analysis pending enrichment.
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | >= 2.32.0, < 2.32.1 | 2.32.1 |
Do you use n8n? You're affected.
How severe is it?
What should I do?
Patch available
Update n8n to version 2.32.1
Which compliance frameworks are affected?
Compliance analysis pending. Sign in for full compliance mapping when available.
Frequently Asked Questions
What is GHSA-64xh-79j6-r5v8?
## 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.
Is GHSA-64xh-79j6-r5v8 actively exploited?
No confirmed active exploitation of GHSA-64xh-79j6-r5v8 has been reported, but organizations should still patch proactively.
How to fix GHSA-64xh-79j6-r5v8?
Update to patched version: n8n 2.32.1.
What is the CVSS score for GHSA-64xh-79j6-r5v8?
No CVSS score has been assigned yet.
What are the technical details?
Original Advisory
## 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.
Weaknesses (CWE)
CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2026-33663 10.0 n8n: member role steals plaintext HTTP credentials
Same package: n8n CVE-2026-33660 10.0 TensorFlow: type confusion NPD in tensor conversion
Same package: n8n CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same package: n8n CVE-2026-27495 9.9 n8n: Code Injection enables RCE
Same package: n8n CVE-2026-27577 9.9 n8n: Code Injection enables RCE
Same package: n8n