EUVD-2026-52657Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-delivered with no attacker privileges required, but victim must follow a crafted link (UI:R); C:L and I:L reflect session confusion or account-linking impact without availability effect.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
Lifecycle Timeline
2DescriptionCVE.org
Cross-Site Request Forgery vulnerability in Erlang Ecosystem Foundation oidcc_plug (Oidcc.Plug.AuthorizationCallback module) allows an attacker to make a victim's browser complete an authorization flow the victim never initiated.
This vulnerability is associated with program file lib/oidcc/plug/authorization_callback.ex and program routine Oidcc.Plug.AuthorizationCallback.call/2.
A callback request that carries no Oidcc.Plug.Authorize session is processed with every security check disabled rather than being rejected. call/2 substitutes permissive defaults for the absent session, and each downstream check treats its value as nothing to compare and returns :ok, so the nonce, state, PKCE, peer IP and user agent checks are all skipped. A separate clause of check_state/2 also accepts a state-less request when a verifier is present.
An attacker obtains an authorization code for their own provider account, then induces the victim to visit the callback endpoint with that code and no state parameter. The application signs the victim in as the attacker, so the victim's subsequent actions occur in the attacker's account where the attacker can read them. Applications reusing one callback for both signing in and linking a provider account are further exposed to account takeover, the attacker's account becoming linked to the victim's.
The permissive fallback serves no conforming flow. Third-party-initiated login reaches a relying party at a separate login initiation endpoint and causes it to send a fresh authentication request, and this library implements no such endpoint. Oidcc.Plug.Authorize always sends a state parameter, which an authorization server must echo, so no legitimate callback lacks one.
This issue affects oidcc_plug: from 0.2.0-beta.1 before 0.5.0.
AnalysisAI
Login CSRF in oidcc_plug (versions 0.2.0-beta.1 through 0.5.0) enables an attacker to silently sign a victim into the attacker's own identity provider account by luring the victim to a crafted OIDC callback URL carrying the attacker's authorization code. The root cause is that Oidcc.Plug.AuthorizationCallback.call/2 substitutes permissive defaults (:any nonce, :none PKCE and state verifiers) when no prior Oidcc.Plug.Authorize session exists instead of rejecting the stateless request outright, causing every downstream security check - nonce, state, PKCE, peer IP, and user-agent binding - to silently pass against nothing. No public exploit code or CISA KEV listing exists at time of analysis; however, the attack primitive is straightforward for any attacker holding an account at the same identity provider.
Technical ContextAI
oidcc_plug (CPE: cpe:2.3:a:erlang_ecosystem_foundation:oidcc_plug:*:*:*:*:*:*:*:*) is an Elixir/Phoenix Plug library implementing OpenID Connect authorization code flows for the Erlang ecosystem. The authorization callback module (lib/oidcc/plug/authorization_callback.ex) is responsible for receiving the redirect from the identity provider, validating the OIDC state parameter against the originating session, verifying the nonce, checking PKCE, and optionally enforcing peer IP and user-agent binding before exchanging the code for tokens. CWE-352 (Cross-Site Request Forgery) describes the root cause: the Plug.Authorize step writes security material (nonce, state verifier, PKCE verifier, peer IP, user agent) into a server-side session cookie, and the AuthorizationCallback is designed to read that session to validate the incoming callback. When no such session exists, the pre-fix code substituted permissive defaults rather than aborting, so an unsolicited callback - one the victim never initiated - was processed as legitimate. A secondary logic flaw in check_state/2 explicitly returned :ok for stateless requests when the state verifier slot was :none, providing an independent bypass path. The fix (commit 97d75afc) introduces fetch_authorize_session/1 which hard-rejects any callback lacking a structurally valid session, and reverses check_state/2's fallback clause to return {:error, :state_not_verified}.
RemediationAI
Upgrade oidcc_plug to version 0.5.0 or later; the fix is delivered in commit 97d75afc57826dca31989b47d6e2a3c136039917 (https://github.com/erlef/oidcc_plug/commit/97d75afc57826dca31989b47d6e2a3c136039917) and replaces the permissive fallback with strict rejection via the new fetch_authorize_session/1 helper, ensuring all OIDC security checks are enforced unconditionally. If immediate upgrade is not feasible, add application-level Plug middleware earlier in the pipeline that rejects any request to the callback route that lacks both a state query parameter and a valid Oidcc.Plug.Authorize session cookie; this prevents stateless callback requests from reaching the vulnerable call/2 function at the cost of requiring careful implementation to avoid introducing new logic errors. Applications that expose account-linking through the same callback endpoint should prioritize this fix as urgent regardless of the low numeric CVSS score, because in that configuration the impact escalates to full account takeover. The vendor advisory is at https://github.com/erlef/oidcc_plug/security/advisories/GHSA-fg66-w5gp-22cr.
More in Oidcc Plug
View allSame weakness CWE-352 – Cross-Site Request Forgery (CSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today