n8n MCP Server Trigger OAuth Authorization Bypass Leading to Cross-Tenant Workflow Hijack
First seen Jul 22, 2026 · Updated Jul 22, 2026
n8n's OAuth 2.1 consent flow for MCP Server Trigger workflows fails to verify that the requesting user actually owns or has access to the workflow they are authorizing. A low-privileged member-level user can register an OAuth client, self-approve consent for another user's workflow, and obtain a valid token that runs the victim's workflow using the victim's stored credentials. This breaks project/user isolation and lets an attacker read outputs and manipulate tool inputs of an MCP agent tool they should never have access to.
Technical Analysis
The vulnerability is a broken object-level authorization (BOLA) flaw in n8n's OAuth 2.1 token-issuance flow introduced in v2.27.0 for MCP Server Trigger workflows. The authorization server checks that a user is authenticated but does not check that the OAuth 'resource' (the target workflow) belongs to or is accessible by that user, allowing any member-level account to mint a valid token scoped to an arbitrary workflow. Because the MCP Server Trigger executes in the workflow owner's project context, the attacker inherits the owner's connected integration credentials without ever seeing them directly, effectively using the agent tool execution layer as a confused deputy. This crosses tenant/project boundaries within a single n8n instance, letting an unauthorized principal invoke MCP tools, supply crafted tool inputs, and exfiltrate outputs derived from the victim's connected services (e.g., databases, SaaS APIs, email).
Affected Systems
n8n; protocols: MCP,OAuth 2.1
Detection Signatures
- OAuth client registrations followed immediately by token requests specifying a 'resource' parameter/workflow ID not owned by the registering user
- Token issuance logs where consent approval user_id != workflow owner_id
- MCP Server Trigger invocation logs showing execution under a project context different from the authenticated caller's own projects
- Unexpected tool-call activity on MCP Server Trigger workflows from accounts with member-level (non-owner) roles
- Spikes in OAuth client registrations from a single member account across multiple unrelated workflow resources
Remediation Steps
- 1
Upgrade n8n
Update to n8n 2.29.8, 2.30.1, or later where the OAuth resource-ownership check is enforced.
- 2
Enforce object-level authorization on OAuth resource binding
Ensure the OAuth authorization server validates that the requesting/consenting user has explicit access to the workflow/project referenced as the 'resource' before issuing a token.
- 3
Audit existing MCP Server Trigger workflows
Review logs for OAuth token issuance events tied to workflows not owned by the requesting user, and review MCP tool invocation history for anomalous cross-project access.
- 4
Rotate exposed credentials
Rotate stored credentials/integration secrets on any MCP Server Trigger workflows that may have been accessed via this flaw prior to patching.
- 5
Restrict member-level OAuth client registration
As a temporary mitigation, limit which roles can register OAuth clients or approve consent for MCP Server Trigger workflows until patched.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.