CVE-2025-61783

What it actually does

In python-social-auth / social-app-django prior to 5.6.0, the authentication pipeline can bind a newly authenticated third-party identity to an existing local user by matching e-mail addresses even when the associate_by_email pipeline step is not configured. That unintended association issues a session as the matched local user without that user having enabled social linking, constituting an authentication-bypass / account-takeover condition whenever the identity provider asserts an e-mail that already exists in the application user store.

Why it matters to the business

Abuse can produce takeover of existing application accounts, unauthorized access to user data and functions, and possible privilege gain if a high-value account’s e-mail can be asserted by an untrusted provider. Risk is highest for apps that accept social login from providers that do not verify e-mail ownership or uniqueness; many strict providers will not allow this path. Exploit likelihood is low: EPSS is about 0.004 and declined over 30 days, the issue is not in CISA KEV, ransomware use is not reported, and public exploit maturity is none. The advisory has been public for many months, so remaining unpatched Django and Alpaquita linux-lts deployments are an avoidable residual identity risk rather than an emergency mass-exploitation event.

How an attack unfolds

An attacker learns or guesses a victim account e-mail, then authenticates to the application through a social identity provider that does not verify control of asserted e-mails or that permits non-unique addresses. The provider returns an identity whose e-mail matches the victim. On a vulnerable python-social-auth stack, the pipeline associates that social identity with the existing local user even though associate_by_email was never included. The attacker receives a normal authenticated session as the victim. Providers that require verified, unique e-mails largely block this path; no named threat actors or ransomware campaigns are associated with this CVE.

How to fix it

Upgrade python-social-auth / social-app-django to 5.6.0 or later (fix commit d1256b8593b3c3c9168232ce7712ee1cb27333de). On Alpaquita linux-lts, move to 6.1.151-r0 (release 23) or 6.12.51-r0 (stream and 25) as applicable. Until patched, restrict social login to identity providers that verify e-mail ownership and uniqueness, and do not treat unverified provider e-mails as account keys. Review SOCIAL_AUTH pipeline configuration so e-mail association occurs only when explicitly intended.

How to confirm the fix worked

Inventory installations of social-auth-app-django / python-social-auth and confirm version 5.6.0 or later, or the listed Alpaquita linux-lts package versions. After upgrade, confirm that a social login asserting an e-mail already present on another user does not bind identities unless associate_by_email is explicitly in the pipeline. Review allowed backends and each provider’s e-mail verification policy. In staging, attempt a social login with a verified-unique provider versus an unverified-email provider and verify only the intended association behavior occurs.

Typical attack path

1. Identify an application using python-social-auth / social-app-django before 5.6.0 with third-party login enabled.
2. Obtain a target local account’s e-mail address.
3. Authenticate via an identity provider that does not validate e-mail ownership or uniqueness.
4. Complete social login asserting the victim’s e-mail.
5. Vulnerable pipeline associates the social identity to the existing user without associate_by_email being configured.
6. Use the resulting session as the victim to access account data or privileged functions.

How to detect it

Because this is an unintended account-link rather than malware, look for identity-binding anomalies rather than host IOCs. Review application and authentication logs around social-login completion for cases where a new third-party identity was bound to a pre-existing user who never completed an explicit link step, especially when the backend is a provider known not to verify e-mail. Compare social-login success events with user-initiated association events; investigate logins where the social uid is new but the local user is old and the only common attribute is e-mail. Check audit or admin logs for sudden access to privileged accounts immediately after a first-time social-backend login. No public exploit tooling or named campaigns are documented, so detections should be behavioral and application-log based.

• associate_by_email
• social_core.pipeline.social_auth
• social_django.views.complete
• /complete/
• UserSocialAuth
• python-social-auth
• social-auth-app-django

What your security team should do

• Patch social-app-django to 5.6.0+ (or the listed Alpaquita linux-lts versions) on all internet-facing apps that offer social login.
• Disable or tightly restrict backends whose providers do not verify e-mail ownership and uniqueness until patched.
• Audit SOCIAL_AUTH pipelines and remove implicit e-mail association unless product owners explicitly require associate_by_email.
• Hunt historical social-identity bindings that attached a new backend to a pre-existing user without an explicit user-driven link.
• Prioritize internet-exposed Django apps; deprioritize relative to KEV/ransomware issues given low EPSS, no KEV listing, and no known exploit maturity.