Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The generic OpenID Connect backend (`OpenIdConnectAuth` and every backend built on it) stores the `nonce` in the shared Association table, not in the user's session. When the ID token comes back, `validate_claims` only checks that the nonce exists in that table and is not expired. It does not check that the nonce was issued to the browser that is finishing the login. So the nonce does not do its job. OIDC Core (section 15.5.2) and RFC 9700 (section 4.5) use the nonce to stop authorization code injection: an attacker who gets hold of a victim's unused authorization code should not be able to redeem it in the attacker's own browser. With social-auth-core, the attacker can. They start their own login to get a valid `state` for their session, then hit the callback with the victim's `code` and their own `state`. `state` passes because it belongs to the attacker's session, and the nonce in the victim's ID token passes because it is in the global table. The attacker's browser is…
Recommended action: Upgrade to 6.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Applications using the LINE Login backend are vulnerable to login CSRF / forced authentication. An attacker can start a LINE authorization flow for an account they control and trick a victim into visiting the callback URL with the attacker’s authorization code. Because the LINE backend did not validate the returned OAuth state, the application could accept the forged callback and log the victim in as the attacker-controlled LINE account. If account linking is enabled, the same flaw can allow an attacker to link their LINE identity to a victim’s existing authenticated account, creating a persistent unauthorized login path. Patches https://github.com/python-social-auth/social-core/pull/1829 Workarounds Only applications that enable the LINE backend are affected. Credits Thanks to Ta Duc Thien and Duc Anh Nguyen for reproting this via GitHub.
Recommended action: Upgrade to 5.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The partial-pipeline resume mechanism accepted partialtoken as a bearer credential without binding it to the browser session that created it. Applications using resumable partial pipeline steps could allow an attacker to start an authentication flow, obtain a valid partial token and verification data, and cause a victim's browser to resume that attacker-controlled flow. This could authenticate the victim's browser as the attacker's account. The issue affects applications using partial pipeline steps such as mailvalidation or custom steps decorated with @partial. Patches The issue has been fixed by binding partial pipeline resumes to the originating browser session. Users should upgrade to a patched version. Fix: https://github.com/python-social-auth/social-core/pull/1816 https://github.com/python-social-auth/social-docs/pull/444 https://github.com/python-social-auth/social-app-django/pull/1009 Workarounds Applications that cannot upgrade immediately should disable resumable…
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The vk-app backend accepted VK application callback data without verifying the callback signature when the authkey parameter was omitted. Applications using this backend could treat unsigned attacker-controlled data as a verified VK identity. An attacker could choose callback fields such as viewerid, accesstoken, apiid, and apiresult, potentially allowing authentication as an arbitrary VK user ID. The issue affects only applications using the vk-app backend. Patches The issue has been fixed by requiring authkey to be present and valid before callback data is trusted. Users should upgrade to a patched version. Fix: https://github.com/python-social-auth/social-core/pull/1811 Workarounds Applications that cannot upgrade immediately should disable the vk-app backend by removing socialcore.backends.vk.VKAppOAuth2 from SOCIALAUTHAUTHENTICATIONBACKENDS. There is no complete workaround while continuing to use the vulnerable backend. Credits Reported by @lalalala5678 through GitHub…
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The LoginRadius backend did not validate OAuth state during the authentication flow. Applications using this backend were vulnerable to login CSRF. An attacker could cause a victim's browser session to complete authentication using an attacker-controlled LoginRadius token, making the victim authenticated as the attacker's LoginRadius identity. The issue affects only applications using the LoginRadius backend. Patches The issue has been fixed by enabling callback state validation for the LoginRadius backend. Users should upgrade to a patched version. Fix: https://github.com/python-social-auth/social-core/pull/1808 Workarounds Applications that cannot upgrade immediately should disable the LoginRadius backend by removing it from SOCIALAUTHAUTHENTICATIONBACKENDS. There is no complete workaround while continuing to use the vulnerable backend. Credits Reported through GitHub private vulnerability reporting by Liyi Zhou, Ziyue Wang, Strick, Maurice, and Chenchen Yu from the…
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Vend OAuth2 backend used only the numeric Vend userid as the social-auth UID. When multiple Vend shops authenticate through the same application, users from different shops with the same internal Vend user ID could collide in the social-auth association table. A user from one shop could then be authenticated as the local account previously associated with the same numeric user ID from another shop. The issue affects applications using the Vend OAuth2 backend with more than one Vend shop. Patches The issue has been fixed by scoping Vend social-auth UIDs by shop. Users should upgrade to a patched version. Fix: https://github.com/python-social-auth/social-core/pull/1795 Workarounds Applications that cannot upgrade immediately should restrict the Vend OAuth2 backend to a single trusted Vend shop. If Vend authentication is not required, the Vend backend can also be disabled by removing it from SOCIALAUTHAUTHENTICATIONBACKENDS. There is no complete workaround while continuing to…
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The SAML backend accepted SAML responses on the Assertion Consumer Service endpoint without verifying that they matched a previously issued AuthnRequest. Applications using SAML account association could allow an attacker with a valid account on a trusted IdP to link the attacker's SAML identity to a logged-in victim's local account. The attacker could then authenticate through SAML and gain access to the victim's account. The issue affects applications using the SAML backend together with authenticated account association. Patches The issue has been fixed by validating SAML responses against stored AuthnRequest IDs. Users should upgrade to a patched version. Fix: https://github.com/python-social-auth/social-core/pull/1794 Workarounds Applications that cannot upgrade immediately should disable SAML account association for already authenticated users. If SAML login is not required, the SAML backend can also be disabled by removing it from SOCIALAUTHAUTHENTICATIONBACKENDS. There…
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.