social-auth-core EUVD-2026-109993

Exploitation requires three concrete preconditions drawn from the advisory: (1) the target must use OpenIdConnectAuth or a backend built on it with the default DEFAULT_USE_PKCE=False configuration (SOCIAL_AUTH_*_USE_PKCE not enabled) - the PoC controls show that enabling PKCE makes the attack fail with an authorization-code rejection; (2) a victim login must be in progress so that a valid, unredeemed OpenID Connect authorization code exists; and (3) the attacker must actually obtain that victim's unused authorization code. Limiting factors that reduce realistic risk: the attack fails entirely if PKCE is enabled, it depends on timing (the victim's code must still be unredeemed), it requires the victim to perform a login (UI:R), and it is fully remediated by upgrading to 6.2.0, which binds the nonce to the initiating browser session and OAuth state.

This is a genuine authentication/account-takeover flaw (CWE-345 insufficient verification plus CWE-384 session fixation per the GHSA advisory) rated CVSS 6.8 (medium). The supplied vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N is internally consistent with the mechanism: network-reachable (AV:N), no attacker privileges (PR:N), but high complexity (AC:H) because the attacker must first obtain a victim's unused/unredeemed OIDC authorization code, and user interaction (UI:R) because the attack depends on a victim login being in flight. The signals are coherent rather than conflicting: a working proof-of-concept is published in the GHSA advisory (two scripts, mockidp.py and social_nonce.py, with demonstrated '[inject] attacker session completes with victim code' output on 6.1.1), so publicly available exploit code exists, but there is no CISA KEV listing and no EPSS score was provided, so there is no evidence of active or widespread exploitation. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with a medium-priority, patch-this-cycle posture. The practical risk is bounded by two real limiters confirmed in the evidence: exploitation requires the default PKCE-disabled configuration, and it requires harvesting a victim's unused authorization code - the PoC controls show that enabling PKCE causes the attack to fail outright. This is a real priority for anyone running the generic OpenID Connect backend in its default (PKCE-off) mode, but not a drop-everything emergency on the available signals.

A victim begins an OpenID Connect login and the attacker obtains the resulting unused authorization code (e.g. via a leaked redirect or referrer). The attacker starts their own login to obtain a valid OAuth state for their browser, then submits the victim's code with the attacker's state; because the nonce lives in a global association table rather than being bound to the initiating session, nonce validation passes and the attacker's browser ends up authenticated as the victim. A complete working proof-of-concept demonstrating this is published in the GHSA advisory.