CVE-2026-86084

What it actually does

On n8n Enterprise, public OIDC login URL generation and callback handling could complete authentication and issue valid application sessions even when OIDC was not the active authentication method. After an administrator configured an identity provider and later disabled it, the leftover SSO routes still accepted the flow because generateLoginUrl and the callback path did not assert that OIDC login was enabled. Confidentiality impact on the instance is high (session issuance and access to workflows and stored secrets); integrity impact is limited to actions the resulting session can take.

Why it matters to the business

A leftover SSO path can let someone obtain a working login on a workflow automation platform after administrators believed identity-provider login was turned off. n8n often holds API keys, OAuth tokens, and connections to business systems, so an unexpected session can expose process data and downstream services. The issue is moderately scored, is not in CISA KEV, has no reported in-the-wild or ransomware use, and requires a prior OIDC configuration that was later disabled—so blast radius is limited to Enterprise instances with that history, but those instances should still treat it as an access-control failure and patch promptly (about four weeks since publication).

How an attack unfolds

An attacker looks for an n8n Enterprise deployment where OIDC was set up and then switched off without fully removing the identity-provider configuration. They use the still-public OIDC login and callback routes, complete authentication at the previously configured identity provider (or reuse a legitimate IdP session for a user of that provider), and receive a valid n8n session from the callback even though OIDC is not the enabled method. With that session they can operate as a logged-in user against workflows, credentials, and connected automations. No public exploit maturity is reported; success depends on reachability of those routes plus a leftover IdP configuration.

How to fix it

Upgrade n8n to 1.123.76, 2.37.7, or 2.38.2 or later, which add the missing enabled-method check on OIDC login URL generation and callback handling. If you cannot patch immediately, treat disabled OIDC as still dangerous: remove unused identity-provider configuration rather than only toggling it off, restrict network access to SSO login and callback routes, rotate credentials stored in workflows if unauthorized SSO use is possible, and invalidate existing sessions after the upgrade. Confirm the running build matches one of the fixed versions on both self-hosted and containerized deployments.

How to confirm the fix worked

Record the running n8n version and confirm it is 1.123.76, 2.37.7, 2.38.2, or newer on every instance. On a patched host with OIDC not the active method, verify that OIDC login URL generation and callbacks are rejected and that no new session is created from those routes. Review SSO/OIDC configuration to ensure unused identity providers are removed, not merely disabled. After upgrade, confirm existing sessions were issued only through the currently enabled authentication method.

Typical attack path

1. Find an n8n Enterprise instance that previously had OIDC configured and later disabled as the active login method
2. Reach the still-exposed public OIDC login and callback routes
3. Complete authentication against the leftover identity-provider configuration
4. Accept a valid n8n session issued by the callback despite OIDC not being enabled
5. Use the session to read or run workflows and access stored credentials and connected systems

How to detect it

This CVE is not known to be exploited in the wild, so hunting is for unexpected use of OIDC routes while OIDC was not the active method. Review reverse-proxy, WAF, and n8n application logs for requests to OIDC login and callback endpoints, especially after SSO was disabled. Correlate those requests with subsequent session creation or workflow API use. Look for successful OIDC callback completions and new sessions tied to identity-provider subjects when local or non-OIDC auth was supposed to be in force. Preserve logs covering the window from first OIDC setup through disablement and patching; absence of public exploit code means detections will be behavioral (SSO endpoints used while disabled) rather than malware hashes.

• POST /rest/sso/oidc/callback
• GET /rest/sso/oidc/login
• /sso/oidc/callback
• generateLoginUrl
• oidc.service.ee
• assertOidcLoginEnabled
• n8n OIDC callback session issued
• sso-oidc login when OIDC disabled

What your security team should do

• Patch all n8n Enterprise instances to 1.123.76, 2.37.7, or 2.38.2 or later as the primary control
• Inventory instances that ever had OIDC configured, including those where SSO is currently off
• Remove leftover identity-provider settings rather than relying on a disable toggle
• Restrict and monitor access to OIDC login and callback endpoints until upgrades are complete
• Rotate high-value workflow credentials and invalidate sessions if leftover SSO routes were reachable
• Hunt historical access to OIDC routes during periods when OIDC was not the active method