CVE-2026-57175 in social-core
Summary
by MITRE • 09/24/2026
Python Social Auth is a social authentication/registration mechanism. Prior to version 5.0.0, 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. The issue has been fixed in version 5.0.0 by validating SAML responses against stored `AuthnRequest` IDs.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
Python Social Auth is a widely utilized library for implementing social authentication and registration mechanisms within web applications, supporting various providers including OpenID Connect, OAuth2, and Security Assertion Markup Language (SAML). The vulnerability identified in versions prior to 5.0.0 specifically impacts the SAML backend implementation when it is configured with authenticated account association enabled. This configuration allows users to link their existing local accounts on a service provider to identities verified by external identity providers. In this specific context, the library failed to enforce strict binding between incoming authentication requests and previously issued authorization prompts, creating a critical security gap that undermines the integrity of the SAML assertion flow.
The core technical flaw lies in the handling of SAML responses at the Assertion Consumer Service endpoint. According to the SAML 2.0 specification, an Identity Provider must receive an AuthnRequest from a Service Provider before issuing a SAML response containing authentication assertions. This request-response binding ensures that the service provider is expecting and authorizing the specific assertion being received. However, in vulnerable versions of Python Social Auth, the backend accepted any validly signed SAML response without verifying that it corresponded to an AuthnRequest previously generated by the application for a specific user session. This omission effectively decouples the authentication event from its initiating context, allowing responses intended for one purpose or origin to be processed as if they were legitimate continuations of a different flow.
The operational impact of this vulnerability is severe, particularly in scenarios involving account association and linking. An attacker who possesses valid credentials on a trusted Identity Provider can exploit this flaw by crafting or reusing SAML assertions. By intercepting or generating these responses, the attacker can submit them to the vulnerable Service Provider's Assertion Consumer Service endpoint. Because the backend does not validate that the response matches an AuthnRequest associated with the currently logged-in victim's session, it may erroneously associate the attacker's Identity Provider identity with the victim's local account. This allows the attacker to hijack the victim's session or gain unauthorized access to their account by authenticating through SAML as if they were the legitimate user linked to that account.
This vulnerability aligns with CWE-287, which describes Improper Authentication, specifically where an entity is able to impersonate another due to insufficient verification of authentication context. Furthermore, it relates to ATT&CK technique T1098, Account Manipulation, as the attacker modifies or links accounts to gain persistent access. The lack of proper request-response binding also touches upon CWE-345, Insufficient Verification of Data Authenticity, highlighting a failure in ensuring that data received from an external source is genuinely intended for the current transaction context.
The issue has been resolved in version 5.0.0 by implementing strict validation of SAML responses against stored AuthnRequest IDs. This fix ensures that every incoming assertion must correspond to a specific, previously issued request tied to the user's session state. To mitigate this risk, organizations using Python Social Auth should immediately upgrade to version 5.0.0 or later. For applications unable to update promptly due to compatibility constraints, implementing custom middleware to manually verify SAML response bindings against stored requests is recommended as a temporary workaround. Additionally, security teams should audit configurations involving authenticated account association to ensure that no legacy code paths bypass the new validation logic and that all SAML flows strictly adhere to the request-response binding requirements defined in the SAML 2.0 standard.