Social Core
Monthly
Authentication bypass in Python Social Auth (social-core) versions prior to 5.0.0 allows unauthenticated remote attackers to impersonate any VK user when an application uses the vk-app backend, as the backend skips signature verification if the auth_key parameter is omitted. An attacker can forge callback fields such as viewer_id, access_token, api_id, and api_result to authenticate as an arbitrary VK identity, potentially taking over accounts in the target application. The vulnerability is fixed in version 5.0.0, and no public exploit code or active exploitation has been identified at this time.
Login CSRF through partial-pipeline session fixation in the social-core library of Python Social Auth before 5.0.0 allows an unauthenticated remote attacker (PR:N) to seed an authentication flow, harvest the resulting partial_token and verification data, and then induce a victim's browser to resume that attacker-controlled flow so the victim ends up authenticated as the attacker's account. Only applications that use resumable partial pipeline steps - such as the built-in mail_validation step or custom steps decorated with @partial - are exposed; success additionally requires victim interaction (UI:R) and reliable delivery of the attacker's token into the victim's browser, which is why the high attack complexity keeps the CVSS 3.1 base score at 4.2. The impact is limited to authenticating the victim as the attacker (a login-CSRF/session-fixation outcome) rather than taking over the victim's own account, and no public exploit has been identified at time of analysis.
Login CSRF in the LoginRadius backend of Python Social Auth (social-core) before 5.0.0 lets an attacker complete a victim's browser session authentication against an attacker-controlled LoginRadius identity, because the OAuth state parameter is never validated during the callback. Only applications that specifically enable the LoginRadius backend are affected; per the assessed vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N, CVSS 4.3) the attacker must possess a valid LoginRadius token and induce user interaction, and the victim's own account is not compromised - they are simply logged in as the attacker, with no confidentiality impact. No public exploit code was identified at time of analysis and there is no CISA KEV listing; the vendor-released fix is social-core 5.0.0, which enforces callback state validation for LoginRadius.
Account impersonation in Python Social Auth (social-core) before version 5.0.0 allows an authenticated Vend user from one shop to be authenticated as a pre-existing local account that was linked to a user from a different shop sharing the same numeric Vend user_id. Only applications that use the Vend OAuth2 backend and authenticate users from more than one Vend shop are affected; the numeric-ID collision is not attacker-controlled and may be uncommon, but successful exploitation yields full compromise of the colliding local account (CVSS 6.8, AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) with no victim interaction required. No public exploit identified at time of analysis.
SAML account association in python-social-auth (social-core) before 5.0.0 lets an attacker who already holds a valid account on an identity provider trusted by the target application link that SAML identity to a logged-in victim's local account, after which the attacker can authenticate through SAML and access the victim's account. The flaw only reaches deployments that use the SAML backend and enable authenticated account association, and it requires the victim to be logged in and driven through the association flow while the unsolicited SAML response is timed to that session, which is why the assessed vector is network-reachable but high-complexity with user interaction (CVSS:3.1/AV:N/AC:H/PR:L/UI:R, base 6.4). This is a conditional integrity and authentication problem rather than a mass-exploitable emergency; no public exploit identified at time of analysis, and version 5.0.0 resolves it by validating SAML responses against stored AuthnRequest IDs.
Authentication bypass in Python Social Auth (social-core) versions prior to 5.0.0 allows unauthenticated remote attackers to impersonate any VK user when an application uses the vk-app backend, as the backend skips signature verification if the auth_key parameter is omitted. An attacker can forge callback fields such as viewer_id, access_token, api_id, and api_result to authenticate as an arbitrary VK identity, potentially taking over accounts in the target application. The vulnerability is fixed in version 5.0.0, and no public exploit code or active exploitation has been identified at this time.
Login CSRF through partial-pipeline session fixation in the social-core library of Python Social Auth before 5.0.0 allows an unauthenticated remote attacker (PR:N) to seed an authentication flow, harvest the resulting partial_token and verification data, and then induce a victim's browser to resume that attacker-controlled flow so the victim ends up authenticated as the attacker's account. Only applications that use resumable partial pipeline steps - such as the built-in mail_validation step or custom steps decorated with @partial - are exposed; success additionally requires victim interaction (UI:R) and reliable delivery of the attacker's token into the victim's browser, which is why the high attack complexity keeps the CVSS 3.1 base score at 4.2. The impact is limited to authenticating the victim as the attacker (a login-CSRF/session-fixation outcome) rather than taking over the victim's own account, and no public exploit has been identified at time of analysis.
Login CSRF in the LoginRadius backend of Python Social Auth (social-core) before 5.0.0 lets an attacker complete a victim's browser session authentication against an attacker-controlled LoginRadius identity, because the OAuth state parameter is never validated during the callback. Only applications that specifically enable the LoginRadius backend are affected; per the assessed vector (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N, CVSS 4.3) the attacker must possess a valid LoginRadius token and induce user interaction, and the victim's own account is not compromised - they are simply logged in as the attacker, with no confidentiality impact. No public exploit code was identified at time of analysis and there is no CISA KEV listing; the vendor-released fix is social-core 5.0.0, which enforces callback state validation for LoginRadius.
Account impersonation in Python Social Auth (social-core) before version 5.0.0 allows an authenticated Vend user from one shop to be authenticated as a pre-existing local account that was linked to a user from a different shop sharing the same numeric Vend user_id. Only applications that use the Vend OAuth2 backend and authenticate users from more than one Vend shop are affected; the numeric-ID collision is not attacker-controlled and may be uncommon, but successful exploitation yields full compromise of the colliding local account (CVSS 6.8, AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) with no victim interaction required. No public exploit identified at time of analysis.
SAML account association in python-social-auth (social-core) before 5.0.0 lets an attacker who already holds a valid account on an identity provider trusted by the target application link that SAML identity to a logged-in victim's local account, after which the attacker can authenticate through SAML and access the victim's account. The flaw only reaches deployments that use the SAML backend and enable authenticated account association, and it requires the victim to be logged in and driven through the association flow while the unsolicited SAML response is timed to that session, which is why the assessed vector is network-reachable but high-complexity with user interaction (CVSS:3.1/AV:N/AC:H/PR:L/UI:R, base 6.4). This is a conditional integrity and authentication problem rather than a mass-exploitable emergency; no public exploit identified at time of analysis, and version 5.0.0 resolves it by validating SAML responses against stored AuthnRequest IDs.