CVE-2026-65594 in n8n
Summary
by MITRE • 07/22/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/22/2026
This vulnerability exists in n8n versions prior to 2.29.8 and 2.30.x before 2.30.1, specifically affecting instances where the OAuth 2.1 consent and token-issuance flow was introduced in version 2.27.0. The core issue stems from insufficient access control verification during the OAuth authentication process, creating a critical privilege escalation vulnerability that undermines fundamental security boundaries within the platform's multi-tenant architecture.
The technical flaw manifests when a member-level user exploits the workflow access control mechanism by registering their own OAuth client and self-approving consent for another user's workflow. This bypasses the expected authorization checks that should verify whether the authenticated user has legitimate access rights to the target workflow resource. The vulnerability operates through the MCP Server Trigger workflow configuration, where stored credentials are automatically used when the workflow executes, effectively allowing unauthorized users to impersonate workflow owners and execute operations within the owner's project context.
The operational impact of this vulnerability is severe as it completely breaks user and project isolation principles that are fundamental to multi-tenant applications. An attacker with member-level privileges can obtain valid OAuth tokens that grant access to workflows owned by other users, enabling them to manipulate tool inputs and read outputs from connected integrations. This creates a persistent backdoor for data exfiltration and unauthorized automation execution, potentially compromising sensitive business processes and integration endpoints that the workflow owner intended to protect.
This vulnerability maps directly to CWE-285: "Improper Authorization" and aligns with ATT&CK technique T1078.004: "Valid Accounts: Cloud Accounts" in its exploitation of legitimate authentication mechanisms to gain unauthorized access. The issue represents a critical failure in the principle of least privilege, where proper access controls fail to enforce resource boundaries between users and their respective workflow configurations. Organizations using n8n instances with active MCP Server Trigger workflows and OAuth2 authentication are particularly at risk, as this vulnerability enables attackers to escalate privileges without requiring administrative credentials or complex exploitation techniques.
The recommended mitigation involves upgrading to n8n version 2.29.8 or 2.30.1 and later, which implements proper access verification for OAuth workflow resources. Administrators should also review existing workflow configurations to ensure that OAuth2 authentication is properly restricted to authorized users only, and consider implementing additional monitoring for unauthorized OAuth client registrations and consent approvals. Regular security audits of workflow permissions and access controls are essential to prevent similar privilege escalation scenarios in other components of the platform.