CVE-2026-86084: n8n stale OIDC endpoint bypasses

Q: Is CVE-2026-86084 actively exploited?

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

Q: How to fix CVE-2026-86084?

Upgrade n8n to 1.123.76, 2.37.7, or 2.38.2 or later immediately. If your instance ever had OIDC configured (even if since disabled), review authentication logs for unexpected `/rest/sso/oidc/callback` or login activity during the period OIDC was supposedly inactive. As a precaution, rotate credentials stored within n8n (LLM API keys, database creds, third-party tokens) if any suspicious session activity is found. Going forward, when disabling an SSO provider, verify (post-patch) that the corresponding login/callback routes return an explicit rejection rather than silently succeeding.

Q: What systems are affected by CVE-2026-86084?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration.

Q: What is the CVSS score for CVE-2026-86084?

No CVSS score has been assigned yet.

CISO Take

n8n's OIDC login and callback endpoints kept issuing valid sessions even after an Enterprise administrator disabled OIDC as the active authentication method, because the callback flow never checked whether OIDC was still enabled (missing assertOidcLoginEnabled, CWE-288). This matters for any org that piloted or migrated off OIDC in n8n's SSO settings — the old identity-provider trust relationship stays live as a silent backdoor into whatever auth policy replaced it (e.g., password+MFA). There is no CVSS score, no CISA KEV listing, no EPSS data, and no public PoC or Nuclei template yet, so this reads as a logic flaw disclosed responsibly rather than an actively exploited bug — but n8n instances routinely hold credentials for LLM APIs, databases, and other AI agent tool integrations, so a bypassed session has an outsized blast radius. Upgrade immediately to 1.123.76, 2.37.7, or 2.38.2, and if your org ever configured then disabled OIDC, audit login logs for OIDC callback hits and rotate any credentials stored in affected n8n instances as a precaution.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Low-to-moderate exploitability in practice: the flaw only matters for Enterprise customers who configured an OIDC identity provider and later disabled it in favor of another auth method, so exposure is narrow and requires prior knowledge of (or access to) the original IdP relationship. There's no evidence of active exploitation, no KEV entry, no EPSS score, and no public exploit or scanner template. However, impact if triggered is high: a successful callback completion grants a fully valid n8n session, sidestepping whatever access control the admin believed was authoritative. Because n8n is a workflow/agent orchestration platform that frequently stores API keys and service credentials used by connected AI tools, an authenticated attacker session translates directly into credential and workflow-execution compromise.

How does the attack unfold?

Discovery

Attacker identifies that an n8n instance previously configured OIDC SSO and locates the still-active login/callback endpoints.

AML.T0006

Initial Access

Attacker completes the OAuth/OIDC flow against n8n's callback endpoint using access to the original identity provider.

AML.T0049

Authentication Bypass

The callback handler issues a valid n8n session without verifying OIDC is still the enabled active authentication method (missing assertOidcLoginEnabled).

AML.T0012

Impact

Attacker uses the valid session to access stored credentials and manipulate AI agent workflows within n8n.

AML.T0025

Discovery

Attacker identifies that an n8n instance previously configured OIDC SSO and locates the still-active login/callback endpoints.

AML.T0006

Initial Access

Attacker completes the OAuth/OIDC flow against n8n's callback endpoint using access to the original identity provider.

AML.T0049

Authentication Bypass

The callback handler issues a valid n8n session without verifying OIDC is still the enabled active authentication method (missing assertOidcLoginEnabled).

AML.T0012

Impact

Attacker uses the valid session to access stored credentials and manipulate AI agent workflows within n8n.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	< 1.123.76	`1.123.76`
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.3%

chance of exploitation in 30 days

Higher than 18% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade n8n to 1.123.76, 2.37.7, or 2.38.2 or later immediately. If your instance ever had OIDC configured (even if since disabled), review authentication logs for unexpected /rest/sso/oidc/callback or login activity during the period OIDC was supposedly inactive. As a precaution, rotate credentials stored within n8n (LLM API keys, database creds, third-party tokens) if any suspicious session activity is found. Going forward, when disabling an SSO provider, verify (post-patch) that the corresponding login/callback routes return an explicit rejection rather than silently succeeding.

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?

Auth Bypass Agent AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.9 - Information security controls for AI system access

NIST AI RMF

MANAGE-4 - Manage AI system risks including third-party and access risks

Frequently Asked Questions

What is CVE-2026-86084?

n8n's OIDC login and callback endpoints kept issuing valid sessions even after an Enterprise administrator disabled OIDC as the active authentication method, because the callback flow never checked whether OIDC was still enabled (missing assertOidcLoginEnabled, CWE-288). This matters for any org that piloted or migrated off OIDC in n8n's SSO settings — the old identity-provider trust relationship stays live as a silent backdoor into whatever auth policy replaced it (e.g., password+MFA). There is no CVSS score, no CISA KEV listing, no EPSS data, and no public PoC or Nuclei template yet, so this reads as a logic flaw disclosed responsibly rather than an actively exploited bug — but n8n instances routinely hold credentials for LLM APIs, databases, and other AI agent tool integrations, so a bypassed session has an outsized blast radius. Upgrade immediately to 1.123.76, 2.37.7, or 2.38.2, and if your org ever configured then disabled OIDC, audit login logs for OIDC callback hits and rotate any credentials stored in affected n8n instances as a precaution.

Is CVE-2026-86084 actively exploited?

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

How to fix CVE-2026-86084?

Upgrade n8n to 1.123.76, 2.37.7, or 2.38.2 or later immediately. If your instance ever had OIDC configured (even if since disabled), review authentication logs for unexpected `/rest/sso/oidc/callback` or login activity during the period OIDC was supposedly inactive. As a precaution, rotate credentials stored within n8n (LLM API keys, database creds, third-party tokens) if any suspicious session activity is found. Going forward, when disabling an SSO provider, verify (post-patch) that the corresponding login/callback routes return an explicit rejection rather than silently succeeding.

What systems are affected by CVE-2026-86084?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow automation / orchestration.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: A.9

NIST AI RMF: MANAGE-4

What are the technical details?

Original Advisory

n8n is an open source workflow automation platform. Prior to 1.123.76, 2.37.7, and 2.38.2, the public OIDC login and callback endpoints completed authentication even when OIDC was not the enabled active authentication method. An Enterprise administrator who had configured and later disabled an identity provider still exposed a working route that could issue valid sessions. The affected logic is packages/cli/src/modules/sso-oidc/oidc.service.ee.ts, including generateLoginUrl and the callback flow that lacked assertOidcLoginEnabled. This issue is fixed in versions 1.123.76, 2.37.7 and 2.38.2.

Exploitation Scenario

An organization configures n8n Enterprise SSO with an OIDC identity provider, then later disables OIDC and reverts to password-based login (possibly with MFA) as its intended access control. Because `generateLoginUrl` and the callback handler never call `assertOidcLoginEnabled`, the old `/rest/sso/oidc/*` routes remain fully functional. An attacker who still has (or can obtain) valid credentials at the originally-configured IdP — or who compromised the IdP client configuration before it was rotated — completes the OAuth flow against n8n's still-live callback and receives a valid n8n session cookie, entirely bypassing the auth method the admin believed was now authoritative. With that session, the attacker opens the workflow editor, extracts stored AI API keys and downstream service credentials, and can modify or trigger agent workflows to pivot further into connected systems.

Weaknesses (CWE)

CWE-288 Authentication Bypass Using an Alternate Path or Channel Primary CWE-288 Authentication Bypass Using an Alternate Path or Channel Primary CWE-288 Authentication Bypass Using an Alternate Path or Channel

CWE-288 — Authentication Bypass Using an Alternate Path or Channel: The product requires authentication, but the product has an alternate path or channel that does not require authentication.

[Architecture and Design] Funnel all access through a single choke point to simplify how users can access a resource. For every access, perform a check to determine if the user has permissions to access the resource.

Source: MITRE CWE corpus.