GHSA-64xh-79j6-r5v8: n8n AI node credential allowlist

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

Q: How to fix GHSA-64xh-79j6-r5v8?

Upgrade n8n to 2.31.5 or 2.32.1 or later immediately — this is the only complete remediation. Until patched, restrict workflow creation/editing permissions to fully trusted users, restrict credential sharing to fully trusted users only, and audit all credentials that have "Allowed HTTP Request Domains" configured for unexpected sharing relationships with non-owner users. For detection, review n8n execution logs and any egress/network monitoring for AI/LLM nodes making requests to unexpected or newly-added domains outside the credential's intended provider, and rotate any shared LLM API keys that had domain restrictions and broad sharing prior to patching, since the secret may already have been exposed.

Q: What systems are affected by GHSA-64xh-79j6-r5v8?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM API integrations.

Q: What is the CVSS score for GHSA-64xh-79j6-r5v8?

No CVSS score has been assigned yet.

CISO Take

n8n's per-credential "Allowed HTTP Request Domains" allowlist — the control admins use to let a shared credential be used without letting low-privilege users see or redirect its secret — is silently ignored by several AI/LLM nodes when a user sets a custom base or endpoint URL. Any workflow editor with use-only access to a domain-restricted shared credential (e.g. an OpenAI, Anthropic, or other LLM API key) can point the node at an attacker-controlled host, causing n8n to leak the raw secret in the outbound request, then replay that secret directly against the real API or service. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, but this is an insider-threat-class authorization bypass (CWE-863) in a widely deployed AI agent automation platform with 16 downstream dependents and a middling OpenSSF Scorecard (6.6/10). Exposure is scoped tightly — only credentials with domain restrictions configured AND shared with non-owner users are at risk — but where that pattern exists (shared LLM API keys across a team) it fully defeats the intended blast-radius control. Upgrade to n8n 2.31.5 or 2.32.1 immediately; until then, restrict workflow editing and credential sharing to fully trusted users and audit any domain-restricted credential for unexpected sharing relationships.

Sources: GitHub Advisory ATLAS OpenSSF

What is the risk?

Severity is rated high because the bypass fully defeats a security boundary (the domain allowlist) that exists specifically to protect secrets from users who are trusted to use but not view them — this is a privilege-escalation-adjacent authorization flaw, not a simple info leak. Exploitability requires an authenticated, low-privileged insider (a workflow editor with use-only access to an affected shared credential), which narrows the population of viable attackers to internal or already-compromised accounts rather than anonymous internet actors — no public exploit code, Nuclei template, or CISA KEV entry exists, and EPSS data is unavailable. Exposure is conditional: only organizations that (a) configure "Allowed HTTP Request Domains" on a credential AND (b) share that credential with non-owner users are affected, but this is a common pattern for teams centralizing LLM API keys (OpenAI, Anthropic, etc.) across workflows. Given n8n's role as an AI agent orchestration layer with direct access to LLM provider credentials, successful exploitation converts an internal least-privilege violation into full credential compromise against an external AI service.

How does the attack unfold?

Insider Access

A low-privileged workflow editor already has use-only access to a shared n8n credential that has an 'Allowed HTTP Request Domains' allowlist configured.

AML.T0012

Configuration Manipulation

The editor sets an AI/LLM node's user-supplied base or endpoint URL to an attacker-controlled host, since the node does not enforce the allowlist against this field.

AML.T0081

Credential Exfiltration

When the workflow executes, n8n sends the request — including the credential secret — to the attacker-controlled host instead of the legitimate service.

AML.T0098

Credential Reuse / Impact

The attacker captures the leaked secret and reuses it directly against the underlying AI service (e.g., an LLM provider API), fully bypassing the domain restriction that was meant to contain it.

AML.T0091

Insider Access

A low-privileged workflow editor already has use-only access to a shared n8n credential that has an 'Allowed HTTP Request Domains' allowlist configured.

AML.T0012

Configuration Manipulation

The editor sets an AI/LLM node's user-supplied base or endpoint URL to an attacker-controlled host, since the node does not enforce the allowlist against this field.

AML.T0081

Credential Exfiltration

When the workflow executes, n8n sends the request — including the credential secret — to the attacker-controlled host instead of the legitimate service.

AML.T0098

Credential Reuse / Impact

The attacker captures the leaked secret and reuses it directly against the underlying AI service (e.g., an LLM provider API), fully bypassing the domain restriction that was meant to contain it.

AML.T0091

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.32.0, < 2.32.1	`2.32.1`
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade n8n to 2.31.5 or 2.32.1 or later immediately — this is the only complete remediation. Until patched, restrict workflow creation/editing permissions to fully trusted users, restrict credential sharing to fully trusted users only, and audit all credentials that have "Allowed HTTP Request Domains" configured for unexpected sharing relationships with non-owner users. For detection, review n8n execution logs and any egress/network monitoring for AI/LLM nodes making requests to unexpected or newly-added domains outside the credential's intended provider, and rotate any shared LLM API keys that had domain restrictions and broad sharing prior to patching, since the secret may already have been exposed.

How is it classified?

Auth Bypass Data Leakage Agent API AML.T0055 - Unsecured Credentials AML.T0081 - Modify AI Agent Configuration AML.T0083 - Credentials from AI Agent Configuration AML.T0098 - AI Agent Tool Credential Harvesting

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MANAGE 4.1 - Post-deployment monitoring for AI system risks including third-party/shared resources

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is GHSA-64xh-79j6-r5v8?

n8n's per-credential "Allowed HTTP Request Domains" allowlist — the control admins use to let a shared credential be used without letting low-privilege users see or redirect its secret — is silently ignored by several AI/LLM nodes when a user sets a custom base or endpoint URL. Any workflow editor with use-only access to a domain-restricted shared credential (e.g. an OpenAI, Anthropic, or other LLM API key) can point the node at an attacker-controlled host, causing n8n to leak the raw secret in the outbound request, then replay that secret directly against the real API or service. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, but this is an insider-threat-class authorization bypass (CWE-863) in a widely deployed AI agent automation platform with 16 downstream dependents and a middling OpenSSF Scorecard (6.6/10). Exposure is scoped tightly — only credentials with domain restrictions configured AND shared with non-owner users are at risk — but where that pattern exists (shared LLM API keys across a team) it fully defeats the intended blast-radius control. Upgrade to n8n 2.31.5 or 2.32.1 immediately; until then, restrict workflow editing and credential sharing to fully trusted users and audit any domain-restricted credential for unexpected sharing relationships.

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?

Upgrade n8n to 2.31.5 or 2.32.1 or later immediately — this is the only complete remediation. Until patched, restrict workflow creation/editing permissions to fully trusted users, restrict credential sharing to fully trusted users only, and audit all credentials that have "Allowed HTTP Request Domains" configured for unexpected sharing relationships with non-owner users. For detection, review n8n execution logs and any egress/network monitoring for AI/LLM nodes making requests to unexpected or newly-added domains outside the credential's intended provider, and rotate any shared LLM API keys that had domain restrictions and broad sharing prior to patching, since the secret may already have been exposed.

What systems are affected by GHSA-64xh-79j6-r5v8?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM API integrations.

What is the CVSS score for GHSA-64xh-79j6-r5v8?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM API integrations

MITRE ATLAS Techniques

AML.T0055 Unsecured Credentials

AML.T0081 Modify AI Agent Configuration

AML.T0083 Credentials from AI Agent Configuration

AML.T0098 AI Agent Tool Credential Harvesting

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM02

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.

Exploitation Scenario

A finance-ops team shares an OpenAI API key credential across several n8n workflows, configuring "Allowed HTTP Request Domains" to api.openai.com so that junior workflow builders can use the key without being able to view or exfiltrate it directly. A low-privileged workflow editor with use-only access to that credential edits an AI/LLM node and sets its base URL field to an attacker-controlled server they control (e.g., a webhook.site-style endpoint or their own VPS). Because the node doesn't enforce the domain allowlist against this user-supplied URL, n8n sends the request — including the OpenAI API key — to the attacker's server instead of OpenAI. The attacker captures the key from their server logs and reuses it directly against the OpenAI API, now with full access to a credential that was explicitly scoped to prevent exactly this kind of extraction, resulting in unauthorized API usage, billing abuse, or further data exposure depending on what the key can access.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary

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.