CVE-2026-65596: n8n GraphQL node bypasses domain

Q: Is CVE-2026-65596 actively exploited?

No confirmed active exploitation of CVE-2026-65596 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-65596?

1) Upgrade n8n to 1.123.64, 2.29.8, or 2.30.1 (or later) as soon as feasible. 2) Until patched, audit which credentials have "Allowed HTTP Request Domains" configured and are shared with non-owner users; temporarily restrict sharing of those credentials or revoke workflow-edit access for non-trusted users. 3) Review existing workflows for GraphQL nodes with endpoints pointing outside expected/allowlisted domains. 4) Monitor outbound HTTP traffic from the n8n instance/host for connections to unexpected external domains. 5) Rotate any credential suspected of exposure via a GraphQL node prior to patching. 6) After patching, re-verify that domain restrictions are enforced consistently across all HTTP-capable node types, not just HTTP Request and GraphQL.

Q: What systems are affected by CVE-2026-65596?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration pipelines, plugin/tool integrations.

Q: What is the CVSS score for CVE-2026-65596?

No CVSS score has been assigned yet.

CISO Take

n8n's GraphQL node fails to enforce the "Allowed HTTP Request Domains" restriction that the HTTP Request node already respects, so any authenticated user who can create or edit a workflow can point the GraphQL node at a server they control and have n8n forward a restricted credential's auth headers, basic-auth secret, or OAuth token to it. There is no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template, so this is not a mass-exploitation risk today — it requires an already-authenticated user with workflow-edit rights and only matters where a domain-restricted credential is also shared with non-owner users. The exposure still matters because n8n increasingly sits at the center of AI agent orchestration with 16 tracked downstream dependents and a history of 150 prior CVEs in the package, and organizations lean on credential-sharing restrictions precisely to let multiple teams build workflows against shared API keys and OAuth tokens without full trust. Any tenant that grants workflow-authoring rights to users who don't own the underlying credential should assume, until patched, that those credentials can be silently exfiltrated via a GraphQL node. Patch to n8n 1.123.64, 2.29.8, or 2.30.1, and in the interim tighten who can author/edit workflows and avoid sharing domain-restricted credentials with non-owner users; audit existing workflows for GraphQL nodes pointing at unfamiliar endpoints and monitor outbound HTTP from the n8n instance for unexpected domains.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Moderate risk despite the absence of a CVSS score or KEV/EPSS signal. Exploitability is high for the specific precondition it requires (authenticated user with workflow create/edit rights, no additional privilege escalation needed) but the blast radius is scoped to instances that both configure "Allowed HTTP Request Domains" on a credential and share that credential with non-owner users — a common pattern in multi-team n8n deployments but not universal. There is no evidence of active exploitation, public PoC, or scanner coverage, so opportunistic mass exploitation is unlikely; the realistic threat model is an insider, a compromised low-privilege account, or a malicious collaborator in a shared n8n instance.

How does the attack unfold?

Precondition: authenticated low-privilege access

Attacker holds an n8n account with workflow create/edit rights but does not own a credential that has domain-restriction ('Allowed HTTP Request Domains') configured.

AML.T0012

Weaponize workflow

Attacker adds a GraphQL node to a workflow, configures its endpoint to an attacker-controlled server, and attaches the restricted shared credential to it.

AML.T0098

Bypass and exfiltrate

On execution, the GraphQL node ignores the domain allowlist and sends the credential's auth headers/OAuth token to the attacker's server.

AML.T0025

Impact: credential compromise

Attacker obtains a valid credential for the downstream service and can use it directly to access or abuse that third-party system outside of n8n.

AML.T0053

Precondition: authenticated low-privilege access

Attacker holds an n8n account with workflow create/edit rights but does not own a credential that has domain-restriction ('Allowed HTTP Request Domains') configured.

AML.T0012

Weaponize workflow

Attacker adds a GraphQL node to a workflow, configures its endpoint to an attacker-controlled server, and attaches the restricted shared credential to it.

AML.T0098

Bypass and exfiltrate

On execution, the GraphQL node ignores the domain allowlist and sends the credential's auth headers/OAuth token to the attacker's server.

AML.T0025

Impact: credential compromise

Attacker obtains a valid credential for the downstream service and can use it directly to access or abuse that third-party system outside of n8n.

AML.T0053

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.64	`1.123.64`
204.1K OpenSSF 6.6 16 dependents Pushed 7d 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

0.2%

chance of exploitation in 30 days

Higher than 11% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

1) Upgrade n8n to 1.123.64, 2.29.8, or 2.30.1 (or later) as soon as feasible. 2) Until patched, audit which credentials have "Allowed HTTP Request Domains" configured and are shared with non-owner users; temporarily restrict sharing of those credentials or revoke workflow-edit access for non-trusted users. 3) Review existing workflows for GraphQL nodes with endpoints pointing outside expected/allowlisted domains. 4) Monitor outbound HTTP traffic from the n8n instance/host for connections to unexpected external domains. 5) Rotate any credential suspected of exposure via a GraphQL node prior to patching. 6) After patching, re-verify that domain restrictions are enforced consistently across all HTTP-capable node types, not just HTTP Request and GraphQL.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage Agent Plugin AML.T0012 - Valid Accounts AML.T0025 - Exfiltration via Cyber Means AML.T0053 - AI Agent Tool Invocation 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

MEASURE 2.7 - AI system security and resilience evaluated and documented

OWASP LLM Top 10

LLM07 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-65596?

n8n's GraphQL node fails to enforce the "Allowed HTTP Request Domains" restriction that the HTTP Request node already respects, so any authenticated user who can create or edit a workflow can point the GraphQL node at a server they control and have n8n forward a restricted credential's auth headers, basic-auth secret, or OAuth token to it. There is no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template, so this is not a mass-exploitation risk today — it requires an already-authenticated user with workflow-edit rights and only matters where a domain-restricted credential is also shared with non-owner users. The exposure still matters because n8n increasingly sits at the center of AI agent orchestration with 16 tracked downstream dependents and a history of 150 prior CVEs in the package, and organizations lean on credential-sharing restrictions precisely to let multiple teams build workflows against shared API keys and OAuth tokens without full trust. Any tenant that grants workflow-authoring rights to users who don't own the underlying credential should assume, until patched, that those credentials can be silently exfiltrated via a GraphQL node. Patch to n8n 1.123.64, 2.29.8, or 2.30.1, and in the interim tighten who can author/edit workflows and avoid sharing domain-restricted credentials with non-owner users; audit existing workflows for GraphQL nodes pointing at unfamiliar endpoints and monitor outbound HTTP from the n8n instance for unexpected domains.

Is CVE-2026-65596 actively exploited?

No confirmed active exploitation of CVE-2026-65596 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-65596?

1) Upgrade n8n to 1.123.64, 2.29.8, or 2.30.1 (or later) as soon as feasible. 2) Until patched, audit which credentials have "Allowed HTTP Request Domains" configured and are shared with non-owner users; temporarily restrict sharing of those credentials or revoke workflow-edit access for non-trusted users. 3) Review existing workflows for GraphQL nodes with endpoints pointing outside expected/allowlisted domains. 4) Monitor outbound HTTP traffic from the n8n instance/host for connections to unexpected external domains. 5) Rotate any credential suspected of exposure via a GraphQL node prior to patching. 6) After patching, re-verify that domain restrictions are enforced consistently across all HTTP-capable node types, not just HTTP Request and GraphQL.

What systems are affected by CVE-2026-65596?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration pipelines, plugin/tool integrations.

What is the CVSS score for CVE-2026-65596?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration pipelinesplugin/tool integrations

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0025 Exfiltration via Cyber Means

AML.T0053 AI Agent Tool Invocation

AML.T0098 AI Agent Tool Credential Harvesting

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

n8n before 1.123.64, 2.29.8, and 2.30.1 fails to enforce the "Allowed HTTP Request Domains" restriction on HTTP-based credentials (Header Auth, Basic Auth, Query Auth, OAuth) in the GraphQL node, unlike the HTTP Request node. An authenticated user able to create or edit workflows can point the node's endpoint at a server they control and exfiltrate restricted credentials. Only instances where a credential has "Allowed HTTP Request Domains" configured and is usable by non-owner users are affected.

Exploitation Scenario

A marketing analyst has workflow-edit rights in a shared n8n instance but does not own the OAuth credential used to call the company's AI vendor API, which has "Allowed HTTP Request Domains" locked to the vendor's domain. The analyst adds a GraphQL node to an existing (or new) workflow, points its endpoint at an attacker-controlled listener (e.g., a webhook capture service), attaches the restricted OAuth credential to the node, and executes the workflow. n8n sends the credential's Authorization header/OAuth token to the attacker's endpoint as part of the GraphQL request, bypassing the domain restriction that would have blocked the same action via the HTTP Request node. The attacker now holds a valid token for the AI vendor's API and can use it to query or abuse that service directly, independent of n8n.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary CWE-863 Incorrect Authorization Primary CWE-863 Incorrect Authorization

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.