CVE-2024-32879

What it actually does

Due to default case-insensitive collation in MySQL or MariaDB, third-party authentication user IDs are matched without regard to case, allowing distinct IDs to collide and grant unintended access.

Why it matters to the business

Attackers may gain unauthorized access to user accounts through social login, increasing risk of account takeover, data exposure, and compliance violations in applications relying on this library.

How an attack unfolds

An attacker obtains or registers a third-party identity whose user ID differs from a target account only in letter case, then initiates social authentication; the database match succeeds due to collation, bypassing intended identity separation.

How to fix it

Upgrade python-social-auth/social-app-django to the commit 593ee4638eab9b1d9f252393a21ead643e3ceae6 (version 5.4.1 equivalent). As a workaround, alter the collation of the affected user ID field to a case-sensitive setting such as utf8mb4_bin.

How to confirm the fix worked

Confirm the installed package version includes commit 593ee4638eab9b1d9f252393a21ead643e3ceae6 and verify the database column storing third-party user IDs uses a case-sensitive collation.

Typical attack path

1. Locate a target account using social authentication
2. Obtain or create a third-party identity whose ID collides ignoring case
3. Perform authentication via the social provider
4. Receive authenticated session for the target account

How to detect it

Search authentication logs for social login events where user IDs match existing accounts when case is ignored; inspect database queries involving the social auth UID field for unexpected matches.

What your security team should do

• Apply the library upgrade or collation change immediately
• Audit all social authentication flows for case-sensitivity assumptions
• Review authentication logs for recent collisions or anomalous logins