CVE-2026-65594: n8n authz bypass hijacks other

Q: Is CVE-2026-65594 actively exploited?

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

Q: How to fix CVE-2026-65594?

Upgrade to n8n 2.29.8 or 2.30.1+ immediately, which restores the ownership check between the OAuth resource and the requesting user. Until patched: audit all workflows using MCP Server Trigger with n8n OAuth2 auth and temporarily disable or restrict this trigger type for shared/multi-user instances; review recently issued OAuth tokens and consent approvals for mismatches between the approving user and the workflow owner; rotate credentials stored in any workflow suspected of cross-user access; and enforce least-privilege project/workspace separation so member-level users don't share an instance with workflows holding sensitive integration credentials. Detection: monitor n8n audit/access logs for OAuth client registrations and consent approvals where the acting user differs from the workflow's owning user.

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

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent tool/plugin invocation (MCP), multi-tenant SaaS orchestration.

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

No CVSS score has been assigned yet.

CISO Take

A missing ownership check in n8n's OAuth 2.1 consent flow lets any member-level user on a shared instance register an OAuth client, self-approve consent for a workflow they don't own, and obtain a valid token that runs that workflow in the owner's project context with the owner's stored credentials. There is no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, but the flaw sits directly in n8n's MCP Server Trigger feature — the mechanism n8n exposes so AI agents can call workflows as tools — meaning exploitation compromises the agent-to-integration trust boundary rather than a peripheral admin function. Any multi-user n8n deployment (16 downstream dependents, OpenSSF score 6.6/10, 150 other CVEs recorded against this package) running at least one active MCP Server Trigger workflow with n8n OAuth2 auth is exposed, and successful exploitation lets the attacker read data and outputs surfaced through the victim's connected integrations. Patch to n8n 2.29.8 or 2.30.1+ immediately; in the interim, inventory workflows using MCP Server Trigger + n8n OAuth2, restrict or rotate credentials tied to them, and alert on OAuth consent/token-issuance events referencing workflows the requesting user does not own.

Sources: NVD GitHub Advisory OpenSSF ATLAS vulncheck.com

What is the risk?

No CVSS/EPSS score is published and there's no KEV listing, public exploit, or scanner template, so opportunistic mass exploitation is unlikely today. However, exploitability for an insider or compromised low-privilege account is straightforward: it requires only a valid member-level login plus knowledge of OAuth client registration and consent self-approval (CWE-863, incorrect authorization) — no code execution, memory corruption, or deep ML expertise needed. Impact is high within scope: full breach of user/project isolation, exposure of another user's connected-integration data, and the ability to drive their workflow's tool inputs/outputs. Real-world risk is concentrated in shared/team n8n instances (SaaS n8n Cloud or self-hosted multi-tenant setups) that have adopted MCP Server Trigger for AI agent tool exposure — a growing deployment pattern — making this a privilege-escalation-via-agent-tooling issue rather than a purely traditional web bug.

How does the attack unfold?

Initial Access

Attacker holds a valid but low-privileged member-level account on a shared n8n instance.

AML.T0012

Authorization Bypass

Attacker registers an OAuth client and self-approves consent for another user's workflow, exploiting the missing ownership check to obtain a valid access token.

AML.T0091.000

Tool Invocation

Attacker uses the token to invoke the victim's MCP Server Trigger workflow, which executes in the owner's project context with the owner's stored credentials.

AML.T0053

Impact

Attacker sets tool inputs and reads outputs, exfiltrating data surfaced through the owner's connected integrations and breaking user/project isolation.

AML.T0086

Initial Access

Attacker holds a valid but low-privileged member-level account on a shared n8n instance.

AML.T0012

Authorization Bypass

Attacker registers an OAuth client and self-approves consent for another user's workflow, exploiting the missing ownership check to obtain a valid access token.

AML.T0091.000

Tool Invocation

Attacker uses the token to invoke the victim's MCP Server Trigger workflow, which executes in the owner's project context with the owner's stored credentials.

AML.T0053

Impact

Attacker sets tool inputs and reads outputs, exfiltrating data surfaced through the owner's connected integrations and breaking user/project isolation.

AML.T0086

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	>= 2.30.0, < 2.30.1	`2.30.1`
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.3%

chance of exploitation in 30 days

Higher than 19% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade to n8n 2.29.8 or 2.30.1+ immediately, which restores the ownership check between the OAuth resource and the requesting user. Until patched: audit all workflows using MCP Server Trigger with n8n OAuth2 auth and temporarily disable or restrict this trigger type for shared/multi-user instances; review recently issued OAuth tokens and consent approvals for mismatches between the approving user and the workflow owner; rotate credentials stored in any workflow suspected of cross-user access; and enforce least-privilege project/workspace separation so member-level users don't share an instance with workflows holding sensitive integration credentials. Detection: monitor n8n audit/access logs for OAuth client registrations and consent approvals where the acting user differs from the workflow's owning user.

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 Privacy Violation Agent Plugin AML.T0012 - Valid Accounts AML.T0053 - AI Agent Tool Invocation AML.T0086 - Exfiltration via AI Agent Tool Invocation AML.T0091.000 - Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Annex A.6 - AI system access control and resource authorization

NIST AI RMF

GOVERN-1.5 - Policies and procedures for access to AI system components

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-65594?

A missing ownership check in n8n's OAuth 2.1 consent flow lets any member-level user on a shared instance register an OAuth client, self-approve consent for a workflow they don't own, and obtain a valid token that runs that workflow in the owner's project context with the owner's stored credentials. There is no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, but the flaw sits directly in n8n's MCP Server Trigger feature — the mechanism n8n exposes so AI agents can call workflows as tools — meaning exploitation compromises the agent-to-integration trust boundary rather than a peripheral admin function. Any multi-user n8n deployment (16 downstream dependents, OpenSSF score 6.6/10, 150 other CVEs recorded against this package) running at least one active MCP Server Trigger workflow with n8n OAuth2 auth is exposed, and successful exploitation lets the attacker read data and outputs surfaced through the victim's connected integrations. Patch to n8n 2.29.8 or 2.30.1+ immediately; in the interim, inventory workflows using MCP Server Trigger + n8n OAuth2, restrict or rotate credentials tied to them, and alert on OAuth consent/token-issuance events referencing workflows the requesting user does not own.

Is CVE-2026-65594 actively exploited?

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

How to fix CVE-2026-65594?

Upgrade to n8n 2.29.8 or 2.30.1+ immediately, which restores the ownership check between the OAuth resource and the requesting user. Until patched: audit all workflows using MCP Server Trigger with n8n OAuth2 auth and temporarily disable or restrict this trigger type for shared/multi-user instances; review recently issued OAuth tokens and consent approvals for mismatches between the approving user and the workflow owner; rotate credentials stored in any workflow suspected of cross-user access; and enforce least-privilege project/workspace separation so member-level users don't share an instance with workflows holding sensitive integration credentials. Detection: monitor n8n audit/access logs for OAuth client registrations and consent approvals where the acting user differs from the workflow's owning user.

What systems are affected by CVE-2026-65594?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent tool/plugin invocation (MCP), multi-tenant SaaS orchestration.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI agent tool/plugin invocation (MCP)multi-tenant SaaS orchestration

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0053 AI Agent Tool Invocation

AML.T0086 Exfiltration via AI Agent Tool Invocation

AML.T0091.000 Application Access Token

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6

NIST AI RMF: GOVERN-1.5

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

n8n before 2.29.8 and 2.30.x before 2.30.1 (affected from 2.27.0, when the OAuth 2.1 consent and token-issuance flow was introduced) does not verify that the authenticated user has access to the workflow referenced as the OAuth resource. On instances with at least one active MCP Server Trigger workflow configured with n8n OAuth2 authentication, a member-level user can register an OAuth client, self-approve consent for another user's workflow, and obtain a valid token. The workflow then runs in the owner's project context with the owner's stored credentials, and the attacker can set tool inputs and read outputs (potentially including data from the owner's connected integrations), breaking user and project isolation.

Exploitation Scenario

An attacker holds a legitimate but low-privileged 'member' account on a shared n8n instance used for AI agent orchestration. They identify a workflow — owned by another user — configured with an MCP Server Trigger and n8n OAuth2 authentication, likely one wired to valuable connected integrations (e.g., Slack, a cloud provider, or a customer database). The attacker registers their own OAuth client against the instance, initiates the consent flow referencing the victim's workflow as the OAuth resource, and self-approves consent since n8n never verifies they actually have access to that workflow. With the resulting valid token, they invoke the workflow's MCP tool interface: it executes in the victim's project context using the victim's stored credentials, letting the attacker set arbitrary tool inputs and read the outputs — including any data retrieved through the owner's connected integrations — all without ever touching the victim's actual account or credentials directly.

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.