chore(deps): update dependency social-auth-app-django to v5.6.0 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
social-auth-app-django (changelog)	5.4.3 → 5.6.0

GitHub Vulnerability Alerts

CVE-2025-61783

Impact

Upon authentication, the user could be associated by e-mail even if the associate_by_email pipeline was not included. This could lead to account compromise when a third-party authentication service does not validate provided e-mail addresses or doesn't require unique e-mail addresses.

Patches

• https://github.com/python-social-auth/social-app-django/pull/803

Workarounds

Review the authentication service policy on e-mail addresses; many will not allow exploiting this vulnerability.

---

Release Notes

python-social-auth/social-app-django (social-auth-app-django)

v5.6.0

Compare Source

Changed

• Fixed possibly unsafe account association (CVE-2025-61783)
• Storage now filters for active users, you might need to customize SOCIAL_AUTH_ACTIVE_USERS_FILTER if your custom model does not have the is_active field

Added

• Django 6.0 and Python 3.14 compatibility
• Type annotations
• LoginRequiredMiddleware compatibility
• RAISE_EXCEPTIONS and LOGIN_ERROR_URL can be configured per backend

v5.5.1

Compare Source

Changed

• Fixed authentication with OpenID based services

v5.5.0

Compare Source

Changed

• Dropped support for older Django versions.
• Added non-empty constraind on uid.
• Added support for session restore with stricter SameSite cookie policy.

---

Configuration

📅 Schedule: Branch creation - "" in timezone US/Eastern, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled because a matching PR was automerged previously.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[pdpinch]

Will this PR require a migration?

[asajjad2]

@pdpinch yes, there are a few django migrations that are added in this change http://github.com/python-social-auth/social-app-django/compare/5.4.3...5.7.0. Should I proceed with this?

[pdpinch]

How many rows do you think this will affect in RC and in production? How long do you think it might take to run? Can the migration be reverted if we need to?

After some recent changes we made, I don't expect the migration to be blocking while it's running. What do you think?

[asajjad2]

@pdpinch Though there are changes in a few migration files, the only new migration I see, adds a NOT NULL constraint to the uid field in UserSocialAuth. It will scan all existing rows to validate the constraint, then add it. Since I've verified 0 null/empty uid values in RC and production, it should complete quickly (seconds to a few minutes max) and be non-blocking because no data changes are needed.

Validation on RC (total 413 records):

In [1]: from social_django.models import UserSocialAuth

In [2]: bad_count = UserSocialAuth.objects.filter(uid__isnull=True).count() + Us
      ⋮ erSocialAuth.objects.filter(uid='').count()
   ...: print(f"Records with null/empty uid: {bad_count}")
Records with null/empty uid: 0

Validation on Production (total 166628 records):

In [1]: from social_django.models import UserSocialAuth

In [2]: bad_count = UserSocialAuth.objects.filter(uid__isnull=True).count() + Us
      ⋮ erSocialAuth.objects.filter(uid='').count()
   ...: print(f"Records with null/empty uid: {bad_count}")
Records with null/empty uid: 0

The migration can also be reversed, since it only adds a constraint that changes no rows, via python manage.py migrate social_django <previous_migration>.

[pdpinch]

Thanks @asajjad2. Seems like it will be OK to proceed. I would just recommend that you coordinate with @mitodl/devops to schedule the deployment to production.