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.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | >= 2.38.0, < 2.38.1 | 2.38.1 |
Do you use n8n? You're affected.
How severe is it?
What should I do?
1 step-
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?
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:
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
MITRE ATLAS Techniques
AML.T0053 AI Agent Tool Invocation AML.T0084 Discover AI Agent Configuration AML.T0091.000 Application Access Token Compliance Controls Affected
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
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.
References
- github.com/advisories/GHSA-cw9w-vv67-hf73
- nvd.nist.gov/vuln/detail/CVE-2026-86073
- github.com/n8n-io/n8n/commit/18458482861097a26f874f30ad7e8136e268475c
- github.com/n8n-io/n8n/commit/380788fd9a3264c83161e868026a98731d274d88
- github.com/n8n-io/n8n/pull/37122
- github.com/n8n-io/n8n/pull/37588
- github.com/n8n-io/n8n/releases/tag/n8n@2.37.7
- github.com/n8n-io/n8n/releases/tag/n8n@2.38.1
- github.com/n8n-io/n8n/security/advisories/GHSA-cw9w-vv67-hf73
Timeline
Related Vulnerabilities
CVE-2026-33663 10.0 n8n: member role steals plaintext HTTP credentials
Same package: n8n CVE-2026-33660 10.0 TensorFlow: type confusion NPD in tensor conversion
Same package: n8n CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same package: n8n CVE-2025-68668 9.9 n8n: Protection Bypass circumvents security controls
Same package: n8n CVE-2026-27495 9.9 n8n: Code Injection enables RCE
Same package: n8n