CVE-2026-86073: n8n Workflow Automation OAuth Bypass

CVE-2026-86073 Overview

CVE-2026-86073 is an authorization flaw in n8n, an open source workflow automation platform. The OAuth token endpoint bound the initial access token from an authorization code to the consented resource but failed to bind the associated refresh token. When a client refreshed its token, the server only verified that the requested resource was registered, not that it matched the original grant. An OAuth client approved for one workflow could substitute a different workflow URL in the resource parameter during refresh and receive a valid token for an unapproved workflow the consenting user could access. The issue is tracked as [CWE-863: Incorrect Authorization] and is fixed in n8n versions 2.37.7 and 2.38.1.

Critical Impact
A malicious or compromised OAuth client can escalate access from a single approved workflow to any workflow the consenting user is permitted to reach, breaking audience isolation between grants.

Affected Products

n8n versions prior to 2.37.7
n8n versions prior to 2.38.1 on the 2.38.x branch
Self-hosted n8n instances exposing the OAuth token endpoint

Discovery Timeline

2026-09-08 - CVE-2026-86073 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86073

Vulnerability Analysis

The defect sits in the OAuth 2.0 token endpoint that handles refresh token grants. n8n implements RFC 8707 resource indicators to scope access tokens to a specific protected resource, in this case a workflow URL exposed as an MCP endpoint. During the initial code exchange, the server correctly bound the issued access token to the resource the user consented to. The refresh token, however, was persisted without any record of its approved audience.

On refresh, the endpoint accepted whatever resource parameter the client supplied and only checked that the resource was a registered target. It never compared the requested resource against the resource that was consented to at authorization time. This is a canonical broken authorization pattern: an authenticated request is treated as an authorized one.

Root Cause

The oauth_refresh_tokens table lacked a column recording the RFC 8707 resource for which the grant was approved. Without that binding, the refresh handler had no server-side truth to enforce against the client-supplied resource parameter. The fix introduces a mandatory resource column on the refresh token entity, populated at mint time and reused unchanged across rotations.

Attack Vector

Exploitation requires an attacker to control an OAuth client that a target user has already approved for at least one workflow resource. The attacker completes a normal authorization flow for workflow A, receives an access token and refresh token, then calls the token endpoint with grant_type=refresh_token and substitutes the resource parameter with the URL of workflow B. The server issues an access token whose audience is workflow B, provided workflow B is registered and reachable by the consenting user. No additional user interaction is required after the initial consent.

typescript

// Patch: bind refresh tokens to the approved resource
// packages/cli/src/modules/oauth-server/database/entities/oauth-refresh-token.entity.ts
	/** OAuth scopes of the originating grant, reissued on every rotation. */
	@JsonColumn()
	scope: string[];

	/**
	 * RFC 8707 resource the grant was approved for — the audience of every access
	 * token minted from it, carried unchanged across rotations. Never null: the
	 * mint path resolves the default resource before the row is written.
	 */
	@Column({ type: 'varchar' })
	resource: string;
}

Source: GitHub Commit 380788fd

Detection Methods for CVE-2026-86073

Indicators of Compromise

Token endpoint requests with grant_type=refresh_token where the submitted resource value differs from the resource recorded on the original authorization code exchange.
Access tokens issued with an audience claim that the user never explicitly consented to during the interactive authorization step.
OAuth clients that refresh tokens against multiple distinct workflow URLs from a single approved grant chain.

Detection Strategies

Correlate authorization code issuance events with subsequent refresh token rotations and alert when the resource parameter changes between the two.
Inventory registered OAuth clients on the n8n instance and flag any client whose refresh activity spans workflows outside the originally consented scope.
Review n8n audit logs for token endpoint calls preceded by no matching consent event for the target workflow.

Monitoring Recommendations

Enable verbose OAuth endpoint logging and forward the events to a centralized log store for retention and analysis.
Monitor the oauth_refresh_tokens table for row counts and rotation frequency, treating unexpected spikes as investigation triggers.
Track outbound calls from workflows that were reached through OAuth tokens to identify data exfiltration paths following an audience swap.

How to Mitigate CVE-2026-86073

Immediate Actions Required

Upgrade n8n to version 2.37.7 on the 2.37.x branch or 2.38.1 on the 2.38.x branch without delay.
Revoke all outstanding OAuth refresh tokens after the upgrade so clients are forced back through the authorization flow with proper resource binding.
Audit recent workflow executions initiated by OAuth clients and confirm the accessed workflows match the consent that authorized them.

Patch Information

The fix is delivered in n8n Release 2.37.7 and n8n Release 2.38.1. Technical details are documented in GitHub Pull Request #37122 and the GitHub Security Advisory GHSA-cw9w-vv67-hf73. The database migration AddResourceToOAuthRefreshTokens1787739515257 adds a mandatory resource column and clears pre-existing rows, requiring clients to re-run the authorization flow on their next refresh.

Workarounds

If patching cannot occur immediately, disable the OAuth server module on the n8n instance to prevent refresh token abuse.
Restrict registered OAuth clients to a single workflow resource per client where operationally feasible.
Place the n8n token endpoint behind a reverse proxy that inspects the resource parameter and rejects refresh requests whose value differs from the original grant.

bash

# Verify installed n8n version and upgrade to a patched release
npm ls n8n
npm install -g n8n@2.38.1
# Or for the 2.37.x branch:
npm install -g n8n@2.37.7

# Force revocation of existing refresh tokens post-upgrade
psql -c "DELETE FROM oauth_refresh_tokens;"