django-allauth CVE-2025-65430

Requires the django-allauth IdP (OAuth2/OpenID Connect identity provider) feature to be in use. The affected party must have been issued access/refresh tokens while their account was active and then had their account set to is_active=False; the flaw is that those previously-issued tokens continued to be accepted. Exploitation is therefore limited to deactivated accounts and only within the lifetime of the already-issued tokens, and it depends on the deployment relying on is_active=False as a revocation mechanism. It does not affect applications that do not use the IdP feature or that revoke sessions by other means.

This is a genuine but moderate-severity session-management flaw (CWE-613, Insufficient Session Expiration) rather than a high-urgency remote code execution 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) is internally consistent with the description: PR:L correctly reflects that the 'attacker' is a legitimate user who was already issued valid OAuth2/OpenID Connect tokens while their account was active, and C:L/I:L capture continued-but-unauthorized access after deactivation. No EPSS score was supplied in the input, so exploitation probability cannot be quantified. The CVE is NOT in CISA KEV and no POC was indicated - exploitation status is 'no public exploit identified at time of analysis.' The real-world risk is constrained by a narrow precondition: it only matters to deployments that use django-allauth's IdP (identity provider) feature AND rely on setting is_active=False to immediately revoke access (e.g., employee offboarding or incident response). For those deployments the flaw is meaningful because revocation silently failed until tokens expired naturally; for everyone else it is low priority. Signals are not conflicting, but key prioritization data (EPSS, KEV, POC) is simply absent and should be treated as unknown rather than low.

A user of an application that uses django-allauth as an OAuth2/OpenID Connect identity provider is issued access and refresh tokens while their account is active. An administrator later deactivates the account (is_active=False) - for example during offboarding or after detecting abuse - expecting access to be cut off. Because the pre-issued access/refresh tokens were not rejected, the deactivated user (or anyone holding those tokens) continues to authenticate and reach protected resources until the tokens expire. No public exploit code is required or known; this is straightforward reuse of already-held tokens (AV:N/AC:L/PR:L).