CVE-2026-86073: n8n: OAuth refresh token skips workflow-resource binding

GHSA-cw9w-vv67-hf73 MEDIUM
Published September 8, 2026
CISO Take

n8n's OAuth token endpoint checks that a refresh request targets a registered resource, but not that it matches the resource the user originally consented to — so a client authorized for one workflow can swap in a different workflow's URL during token refresh and walk away with a valid access token for a workflow it was never approved for. There's no CVSS score, EPSS data, or KEV listing yet, and no public exploit or scanner template exists, so this isn't an imminent mass-exploitation risk — but n8n workflows routinely hold live credentials, API keys, and AI agent tool configurations, so unauthorized access to a workflow can cascade into credential theft or unapproved tool invocation. The attacker must already control (or compromise) an OAuth client with some approved n8n access, which narrows the blast radius mostly to multi-tenant or shared-instance n8n deployments and third-party OAuth integrations. Action: patch to n8n 2.37.7 or 2.38.1 immediately, and audit OAuth client grants/logs for refresh requests whose resource parameter doesn't match the client's original authorization scope.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Moderate risk. This is a broken-access-control bug (CWE-863, incorrect authorization) in the OAuth resource-indicator handling of n8n's token refresh flow, not a remote-unauthenticated exploit — the attacker needs an OAuth client already approved for at least one workflow. Exploitability is straightforward for anyone who understands OAuth 2.0 resource parameters (RFC 8707) and n8n's workflow-as-resource model, but there's no evidence of in-the-wild exploitation, no CISA KEV entry, and no public PoC or Nuclei template. The real risk driver is impact: n8n workflows are frequently AI agent orchestrators wired to credentials, external APIs, and tool integrations, so a token obtained for an unapproved workflow can expose sensitive automation logic and secrets belonging to the consenting user.

How does the attack unfold?

Initial Access
Attacker controls or compromises an OAuth client already approved for access to one specific, low-sensitivity n8n workflow.
AML.T0012
Exploitation
During token refresh, the attacker substitutes a different, higher-value workflow URL in the resource parameter; n8n only checks the resource is registered, not that it matches the original consent.
AML.T0091.000
Unauthorized Access
The attacker receives a valid access token scoped to the unapproved workflow and can inspect its configuration, including any AI agent setup or tool integrations.
AML.T0084
Impact
Attacker extracts embedded credentials/API keys or triggers the unapproved workflow's AI agent tools, exceeding the access the user actually granted.
AML.T0053

What systems are affected?

Package Ecosystem Vulnerable Range Patched
n8n npm >= 2.38.0, < 2.38.1 2.38.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.2%
chance of exploitation in 30 days
Higher than 13% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

1 step
  1. 1) Patch immediately to n8n 2.37.7 (2.37.x branch) or 2.38.1 (2.38.x branch) — both fix the resource-binding check on refresh tokens. 2) Until patched, audit and restrict which OAuth clients are registered against sensitive workflows, and monitor OAuth token refresh logs for resource parameters that differ from the client's original authorization grant. 3) Rotate OAuth client credentials for any client suspected of having accessed unapproved workflows. 4) Review workflow-embedded credentials and API keys for any workflows accessible via OAuth-integrated clients, and rotate those secrets as a precaution if patching was delayed. 5) Post-patch, verify via the GitHub Security Advisory (GHSA-cw9w-vv67-hf73) that the fix commits are present in your deployed version.

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?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.9 - Third-party and customer relationships
NIST AI RMF
GOVERN 3.2 - Third-party AI system access controls
OWASP LLM Top 10
LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-86073?

n8n's OAuth token endpoint checks that a refresh request targets a registered resource, but not that it matches the resource the user originally consented to — so a client authorized for one workflow can swap in a different workflow's URL during token refresh and walk away with a valid access token for a workflow it was never approved for. There's no CVSS score, EPSS data, or KEV listing yet, and no public exploit or scanner template exists, so this isn't an imminent mass-exploitation risk — but n8n workflows routinely hold live credentials, API keys, and AI agent tool configurations, so unauthorized access to a workflow can cascade into credential theft or unapproved tool invocation. The attacker must already control (or compromise) an OAuth client with some approved n8n access, which narrows the blast radius mostly to multi-tenant or shared-instance n8n deployments and third-party OAuth integrations. Action: patch to n8n 2.37.7 or 2.38.1 immediately, and audit OAuth client grants/logs for refresh requests whose resource parameter doesn't match the client's original authorization scope.

Is CVE-2026-86073 actively exploited?

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

How to fix CVE-2026-86073?

1) Patch immediately to n8n 2.37.7 (2.37.x branch) or 2.38.1 (2.38.x branch) — both fix the resource-binding check on refresh tokens. 2) Until patched, audit and restrict which OAuth clients are registered against sensitive workflows, and monitor OAuth token refresh logs for resource parameters that differ from the client's original authorization grant. 3) Rotate OAuth client credentials for any client suspected of having accessed unapproved workflows. 4) Review workflow-embedded credentials and API keys for any workflows accessible via OAuth-integrated clients, and rotate those secrets as a precaution if patching was delayed. 5) Post-patch, verify via the GitHub Security Advisory (GHSA-cw9w-vv67-hf73) that the fix commits are present in your deployed version.

What systems are affected by CVE-2026-86073?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration, OAuth-integrated third-party plugins.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestrationOAuth-integrated third-party plugins

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation
AML.T0084 Discover AI Agent Configuration
AML.T0091.000 Application Access Token

Compliance Controls Affected

ISO 42001: A.9
NIST AI RMF: GOVERN 3.2
OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

n8n is an open source workflow automation platform. Prior to 2.37.7 and 2.38.1, the OAuth token endpoint bound an authorization code's first access token to the consented resource but did not bind its refresh token. Refreshing checked only 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 and obtain a valid token for an unapproved workflow accessible to the consenting user. This issue is fixed in versions 2.37.7 and 2.38.1.

Exploitation Scenario

An attacker controls or compromises a third-party OAuth client that a victim organization has legitimately approved for access to a single, low-sensitivity n8n workflow (e.g., a Slack notification workflow). During the OAuth refresh cycle, the attacker crafts a refresh request whose resource parameter points to a different, higher-value workflow URL — one that orchestrates an AI agent with credentials to internal systems or a CRM. Because n8n only validates that the requested resource is registered somewhere in the instance rather than checking it matches the original grant, the token endpoint issues a valid access token scoped to that unapproved workflow. The attacker then uses this token to read the workflow's configuration, extract embedded credentials or API keys, or trigger/observe the AI agent's tool invocations — all without ever having been granted access to that workflow by the user.

Weaknesses (CWE)

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.

Timeline

Published
September 8, 2026
Last Modified
September 10, 2026
First Seen
September 8, 2026

Related Vulnerabilities