Executive Summary

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]

Useful 0 Not Useful 0

Impact Analysis

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]

Useful 0 Not Useful 0

Detection Guidance

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]

Useful 0 Not Useful 0

Mitigation Strategies

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]

Useful 0 Not Useful 0