django-allauth CVE-2025-65431

Exploitation requires the django-allauth deployment to be configured with the Okta or NetIQ third-party login provider specifically - other providers are unaffected because only these two used the mutable 'preferred_username' claim as the account identifier. The attacker must possess a valid account at that identity provider (PR:L) and be able to set or change their 'preferred_username' value to collide with a target user's identifier; there is no user-interaction requirement (UI:N). Limiting factors: deployments not using Okta/NetIQ SSO are not exploitable, and the IdP's own controls over whether 'preferred_username' can be freely modified by an end user constrain feasibility. Upgrading to django-allauth 65.13.0 (which switches these providers to the immutable 'sub' claim) removes the condition entirely.

This is a moderate-severity authentication/authorization flaw (CWE-287) in django-allauth, not an urgent, widely-exploitable issue. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) indicates network reach but requires the attacker to already hold privileges (PR:L) - consistent with needing a valid account at the identity provider. No EPSS score, KEV listing, or POC was provided, so there is no evidence of active exploitation or public exploit code; the risk is therefore theoretical/targeted rather than widespread. Importantly, exploitation is strictly gated: it only affects deployments that use Okta or NetIQ as third-party (social) login providers, because only those two providers used the mutable 'preferred_username' claim as the account identifier. The practical risk is a targeted account-takeover opportunity where an attacker who can alter their own 'preferred_username' at the IdP to match a victim's could be mapped onto the victim's local account. I would prioritize this for organizations using django-allauth with Okta/NetIQ SSO, and treat it as low urgency otherwise. Note a tension between the vendor-assigned C:L/I:L and the real impact: a successful identifier collision can yield full takeover of the victim's application account, which is arguably higher impact than L/L suggests.

An application uses django-allauth (pre-65.13.0) with Okta or NetIQ SSO. An attacker who controls an account at that identity provider changes their 'preferred_username' to match the value associated with a victim's account; because allauth keyed the local account on this mutable claim rather than the stable 'sub', the attacker's login is mapped onto the victim's account, resulting in account takeover. No public exploit code was identified at time of analysis, and the attack requires the attacker to possess and manipulate an IdP account.