CVE-2026-57175: Improper Authentication in social-auth-core SAML Backend

The social-auth-core package, serving as the core logic library for Python Social Auth, contains an improper authentication vulnerability within its SAML authentication backend. This backend is responsible for facilitating Single Sign-On (SSO) and external identity association with local user accounts. The vulnerability exposes applications to session donation and account takeover when users link their accounts to a federated identity provider.

The root of the flaw lies in the assertion consumer service (ACS) endpoint's processing of unsolicited SAML assertions. In standard SAML service provider (SP) configurations, the application must verify that any incoming assertion corresponds to an active, locally initiated authentication request. Without this validation, the system cannot guarantee that the SAML assertion belongs to the browser session currently interacting with the application.

The primary attack surface is exposed via the account linking or association flow. If an application allows authenticated users to bind external SAML identities to their local profiles, an attacker can manipulate this flow to link their own external identity to a victim's local account. This results in persistent, unauthorized access to the victim's account without requiring the victim's local credentials.

In a secure SAML transaction, state tracking prevents authentication replay and response injection. When a user initiates a sign-in or association flow, the Service Provider generates a unique AuthnRequest ID and stores it in the user's session. The Identity Provider then includes this ID in the InResponseTo attribute of the signed XML assertion, which the Service Provider must validate against its session store.

Prior to version 5.0.0, the SAMLAuth backend in social_core/backends/saml.py completely omitted this validation step. The auth_complete method parsed incoming assertions using the python3-saml library's process_response method without passing the active request_id. Consequently, the underlying library bypassed verification of the InResponseTo attribute, rendering the endpoint receptive to unsolicited responses.

By failing to assert that the received assertion matches an active request initiated by the current session, the backend permits an out-of-band identity mapping. This omission is classified under CWE-287 (Improper Authentication). The system assumes that any validly signed assertion from a trusted Identity Provider is legitimate for the active session, ignoring the contextual origin of the transaction.

The vulnerability is located within the auth_complete method of social_core/backends/saml.py. In the vulnerable code, the method calls auth.process_response() without arguments. This execution path instructs the parser to skip comparing the incoming XML InResponseTo attribute with any expected state, effectively accepting unsolicited login assertions from any trusted IdP.

The patch introduced in version 5.0.0 remediates this by explicitly extracting and verifying the InResponseTo attribute. The application now saves the generated AuthnRequest ID into the session during the auth_url generation phase. Upon receiving the response, the backend retrieves this ID and passes it to the verification logic using constant-time comparison helper functions.

The following diagram illustrates the vulnerable and patched authentication flow path, showing how state tracking is now enforced:

Key additions in the patch include the state-checking logic and session management functions designed to prevent replay attacks by purging the transaction ID from the session cache upon validation.

Exploiting this vulnerability requires the attacker to possess a valid account on a trusted Identity Provider configured in the target application. The attack is executed through a Session Donor methodology. The attacker initiates a standard SAML authentication flow with the shared IdP and intercepts the resulting signed SAMLResponse payload before it is submitted to the Service Provider.

The attacker then delivers this valid SAMLResponse to the victim's active, authenticated session. This delivery can be accomplished through social engineering, such as cross-site request forgery (CSRF), or by tricking the victim into navigating to an association endpoint preloaded with the attacker's SAML assertion. Because the victim's session does not check for a matching request ID, the backend maps the attacker's IdP identity to the victim's local database profile.

Once the association is complete, the attacker logs out of their identity provider and triggers a normal SAML login flow targeting the victim's application. The application authenticates the attacker via the IdP, identifies the mapped association on the victim's local profile, and logs the attacker directly into the victim's account. This achieves full compromise of the victim's session with persistent access.

The security impact of CVE-2026-57175 is characterized by complete unauthorized access to authenticated user accounts, resulting in loss of confidentiality and integrity. If the targeted account belongs to an administrator, the attacker gains full control over application configurations, user data, and system-level operations. The CVSS base score is established at 6.4 (Medium Severity) due to the requirement for specific user interaction and high attack complexity.

The CVSS vector string CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N highlights key operational constraints of the exploit. The attack vector is Network (AV:N), meaning the flaw is exploitable remotely over HTTP. The Attack Complexity is High (AC:H) because the attacker must capture a valid SAML assertion and successfully deliver it to a victim's active session during an account-linking window.

Privileges Required are Low (PR:L) since the attacker only needs standard credentials on a shared Identity Provider. While the vulnerability does not directly impact application availability (A:N), the persistence of the mapped SAML identity allows the attacker to maintain access indefinitely until the association is manually audited and revoked by an administrator.

The primary and recommended mitigation is to upgrade the social-auth-core package to version 5.0.0 or higher immediately. This update modifies the SAMLAuth backend to enforce strict verification of the InResponseTo attribute during the authentication handshake. The updated library also clears the verified request ID from the session cache to prevent subsequent replay attempts.

In environments where immediate package upgrades are not feasible, temporary workarounds must be applied to limit exposure. Administrators should disable the SAML account association feature to prevent authenticated users from linking new external identities to existing profiles. Alternatively, if SAML login is not required, the backend should be removed from the SOCIAL_AUTH_AUTHENTICATION_BACKENDS list within the application settings.

Security teams should also conduct an audit of historic application logs. Check for multiple local accounts linked to the same external SAML NameID, or instances where SAML login associations occurred without a corresponding outbound AuthnRequest log entry. Monitoring network traffic for unexpected requests to ACS endpoints can help identify active exploitation attempts.