CVE-2025-65431
BaseFortify
Publication date: 2025-12-15
Last updated on: 2025-12-23
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| allauth | allauth | to 65.13.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-287 | When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability in django-allauth before version 65.13.0 involved the use of preferred_username as the identifier for third-party provider accounts (specifically Okta and NetIQ). Since preferred_username is mutable, it is insecure to use it for authorization decisions. This could allow unauthorized access or identity confusion. The fix was to switch to using the immutable sub claim as the identifier instead, improving security by preventing issues caused by mutable identifiers. [1]
How can this vulnerability impact me? :
This vulnerability can impact you by allowing potential unauthorized access or incorrect authorization decisions if preferred_username is changed, since it was used as the identifier for third-party accounts. This could lead to security risks such as account takeover or privilege escalation. The update to use the immutable sub claim helps prevent these risks by ensuring stable and secure identification of users. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection involves checking if your django-allauth installation is before version 65.13.0 and if you are using Okta or NetIQ providers relying on preferred_username as the identifier. You can inspect your SocialAccount records to see if the uid field is set to preferred_username instead of sub. For example, you can query your database for SocialAccount entries and examine the uid and extra_data fields. Specific commands depend on your environment, but a Django shell command like `from allauth.socialaccount.models import SocialAccount; accounts = SocialAccount.objects.all(); print([(a.uid, a.extra_data.get('sub')) for a in accounts])` can help identify mismatches. Also, check your installed package version with `pip show django-allauth`. [1]
What immediate steps should I take to mitigate this vulnerability?
Upgrade django-allauth to version 65.13.0 or later to ensure the use of the immutable sub claim instead of preferred_username for third-party provider accounts. After upgrading, manually update existing SocialAccount.uid fields based on the sub value found in SocialAccount.extra_data to maintain correct linkage. Alternatively, if you accept the security risks, you can configure SocialApp.settings to set uid_field to preferred_username. Additionally, ensure that token invalidation on user deactivation is functioning properly as fixed in this release. [1]