n8n Stale OIDC Endpoint Authentication Bypass
First seen Sep 13, 2026 · Updated Sep 13, 2026
n8n's OIDC login and callback endpoints continued to accept and complete authentication flows even after an administrator disabled OIDC as the active login method, allowing sessions to be issued through a supposedly deactivated authentication path. This affects Enterprise instances that had OIDC configured at some point and later turned it off, undermining the assumption that disabling SSO actually revokes that access route. It has been patched in n8n 1.123.76, 2.37.7, and 2.38.2.
Technical Analysis
The public OIDC login/callback routes lacked a runtime check confirming OIDC was the instance's currently enabled authentication method, so they would process the full authorization code/token exchange flow and issue a valid session regardless of configuration state. An attacker (or a user with stale IdP credentials) who still had a functioning client at the identity provider could complete the OIDC flow against the n8n instance and obtain an authenticated session, bypassing the intended access control state set by the administrator. This is a server-side authorization logic flaw rather than an agent-to-agent or LLM-level issue, but it is relevant to AI agent platforms since n8n is widely used to orchestrate AI agent workflows and tool integrations, meaning a bypassed login grants access to configured credentials, API keys, and agent execution pipelines. The fix adds an explicit check requiring OIDC to be the enabled, active method before either endpoint proceeds.
Affected Systems
n8n; protocols: OIDC
Detection Signatures
- Unexpected successful logins via /rest/sso/oidc or OIDC callback endpoints after OIDC was disabled in instance settings
- Authentication logs showing session creation timestamps inconsistent with disabled-auth-method configuration state
- Active IdP client/application entries still valid for an instance where OIDC was turned off
- Anomalous login sessions correlating with old OIDC provider tokens post-disablement
Remediation Steps
- 1
Upgrade n8n
Update to n8n 1.123.76, 2.37.7, 2.38.2 or later where the enabled-method check is enforced before completing OIDC flows.
- 2
Revoke IdP client registration
If unable to upgrade immediately, disable or delete the corresponding OAuth/OIDC client application at the identity provider to prevent the flow from completing.
- 3
Restrict network access
Limit access to the n8n instance's login and callback endpoints to trusted networks or VPN until patched.
- 4
Audit sessions
Review authentication logs for sessions created via OIDC endpoints after the feature was disabled, and force session invalidation/password resets as needed.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.