CVE-2026-57179: Session Fixation and Login CSRF in social-auth-core Partial Pipeline

CVE-2026-57179 is a security vulnerability in the social-auth-core package, a widely adopted authentication library for Python applications. The security flaw exists within the component responsible for processing partial pipelines. This component temporarily pauses authentication flows to complete out-of-band verification steps, such as email or SMS validation.

The attack surface is exposed via endpoints that handle pipeline resumption, specifically endpoints parsing the partial_token request parameter. The core function of this module is to reconstruct the user session from a serialized database state using the provided token. Any public-facing application that implements partial steps under vulnerable versions of the library contains this exposed interface.

This security issue is classified under CWE-384: Session Fixation. By exploiting this flaw, an unauthorized external entity can force a victim's browser session to adopt a pre-configured authentication state. The ultimate impact of this state injection is unauthorized account linking or login CSRF.

The python-social-auth ecosystem utilizes a sequential processing flow known as the pipeline to handle registration and authentication. When an authentication step requires out-of-band input, the pipeline invokes the @partial decorator to pause execution. The current execution state, including variables, arguments, and the specific index of the pipeline, is serialized and saved in the application database or session backend. A unique token, designated as partial_token, is generated as a key to reference this saved state.

The vulnerability arises because the library treats the partial_token as an implicit bearer credential. When resuming the pipeline, the framework retrieves this token from the incoming HTTP request parameters (GET or POST) or the active session. Crucially, the legacy code failed to perform any authorization or origin validation on the token. It did not verify whether the HTTP session presenting the token was the session that initiated the pipeline execution.

Consequently, the application trusted any request containing a valid partial_token to load and resume the stored pipeline state. The underlying architecture assumed that possession of the token was sufficient proof of authorization. This design choice created a logical flaw where the authentication state of one user could be injected directly into the active session of another user.

In the vulnerable implementation of social_core/utils.py, the function partial_pipeline_data extracts the token directly from request parameters without validating the context of the session. The key parts of the vulnerable function logic are as follows:

# Vulnerable Implementation
def partial_pipeline_data(backend, user=None, partial_token=None, *args, **kwargs):
    request_data = backend.strategy.request_data()
    partial_argument_name = backend.setting("PARTIAL_PIPELINE_TOKEN_NAME", "partial_token")
    # The token is read directly from HTTP query arguments without session-binding validation
    partial_token = (
        partial_token
        or request_data.get(partial_argument_name)
        or backend.strategy.session_get(PARTIAL_TOKEN_SESSION_NAME, None)
    )
    if partial_token:
        partial = backend.strategy.partial_load(partial_token)
        # Matches are performed only on static metadata (like user ID), not the active session
        ...
        return partial

The fix introduces a stateful validation structure using PartialPipelineResult and PartialPipelineSelection. The patch ensures that a token is only considered valid if it matches the token registered inside the user's active browser session. The critical validation helper _select_partial_pipeline_token enforces this policy:

# Patched Implementation (0418782454ac7bbc6a9230ea21f7f5066fe89686)
def _select_partial_pipeline_token(request_token, session_token, pending_token, confirmation_requested):
    # Strict validation: Request token must match the session-registered token
    if request_token and request_token == session_token:
        return PartialPipelineSelection(token=request_token, owns_token=True)
    if confirmation_requested and pending_token:
        selected_token = request_token or pending_token
        pending_resume = selected_token == pending_token
        return PartialPipelineSelection(token=selected_token, owns_token=pending_resume, pending_resume=pending_resume)
    if request_token:
        # Token provided does not match session, return owns_token=False
        return PartialPipelineSelection(token=request_token, owns_token=False)
    return PartialPipelineSelection(token=session_token, owns_token=bool(session_token))

The implementation of _select_partial_pipeline_token prevents silent session fixation. If the presenting session does not own the token, the backend blocks automatic resumption. If the pipeline step explicitly allows external resumption (e.g., clicking a validation link received via email), the framework redirects the browser to a confirmation interface rather than silently executing the state transition. This ensures that cross-session token usage requires explicit, visible user interaction.

Exploitation requires specific conditions. First, the target application must incorporate at least one partial pipeline step in its authentication flow, such as mail_validation. Second, the attacker must have network access to the target application to initiate an authentication flow and intercept or capture the resulting partial_token. Finally, the attacker must construct and deliver a malicious URL to a victim who possesses an active session or is capable of authenticating with the target application.

The attacker begins by initiating a login or registration process with a third-party identity provider (e.g., GitHub or Google) on the target application. The attacker proceeds until the application pauses the flow at a partial pipeline step, generating a unique partial_token. The attacker extracts this token from the generated URL or transaction logs without completing the verification step. The attacker then constructs a malicious redirection URL containing the parameter ?partial_token=ATTACKER_TOKEN_VALUE and delivers it to the victim.

When the victim accesses the crafted link, the victim's browser sends the request to the application's completion endpoint. The application loads the attacker's saved pipeline context and binds the attacker's third-party identity to the victim's local application account. Once the binding is established, the attacker can log into the victim's account at any time by executing a normal authentication flow using their own third-party credentials.

The primary consequence of this vulnerability is complete account takeover via session donation or login CSRF. By silently linking an external credential owned by the attacker to the internal account of the victim, the attacker bypasses standard authentication controls. This binding persists even if the victim changes their local password, as the third-party OAuth/OIDC association remains authorized within the application's user database.

The official CVSS v3.1 score is evaluated at 4.2 (Medium), under the vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N. The score reflects the requirement for user interaction and the high complexity involved in orchestrating the state synchronization across multiple independent sessions. However, the operational impact in environments with custom registration steps is high, as it directly undermines identity federation integrity.

There is currently no active exploitation of this vulnerability reported in the wild. The exploit maturity is categorized as proof-of-concept. The CVE is not listed in the Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities catalog.

The primary and most effective remediation is upgrading the social-auth-core package to version 5.0.0 or higher. This version deprecates the insecure @partial decorator and replaces it with @partial_step(save_to_session=True, allow_external_resume=False). Upgrading enforces token ownership checks out of the box and prevents unvalidated cross-session state resumes.

If an immediate package upgrade is unfeasible, developers should remove vulnerable partial steps, such as mail_validation, from the application's authentication pipeline config. Alternatively, applications can manually validate state continuity by implementing custom middleware. This middleware should intercept pipeline completion routes and ensure that incoming request state matches token attributes stored strictly within the current session's encrypted cookies.

For applications that rely on external resume flows (e.g., verifying a user via a confirmation email), developers must configure those steps with allow_external_resume=True. Additionally, they must implement custom confirmation templates. These templates must require the user to explicitly click a confirmation button on the page, generating an anti-CSRF token payload, before resuming the authentication pipeline. This ensures that even if an attacker attempts to inject a token, the action cannot be automated without the user's explicit consent.