CVE-2026-57177: Login Cross-Site Request Forgery in python-social-auth (social-auth-core)

social-auth-core is a Python library that provides a common framework for integrating social authentication and authorization mechanisms into web frameworks such as Django, Flask, and Webpy. The library contains multiple backend plugins corresponding to various identity providers. The LoginRadius authentication backend, implemented in social_core.backends.loginradius.LoginRadiusAuth, is designed to handle user sign-in flows using the third-party LoginRadius identity service.

Prior to version 5.0.0, the LoginRadius backend failed to enforce the generation or verification of the OAuth 2.0 state parameter during authentication. This omission exposes applications relying on this backend to Login Cross-Site Request Forgery (Login CSRF) attacks. This vulnerability is designated as CVE-2026-57177 and GHSA-x7qq-23vw-7pfg, and is classified under CWE-352.

The attack surface exists on the web application's callback endpoint. When a user authenticates via a third-party identity provider, the application must verify that the authentication response corresponds to a request initiated by that same user's browser session. Absent this state check, an attacker can manipulate a victim's session to bind to an identity provider account controlled by the attacker.

The root cause of CVE-2026-57177 lies in the configuration flags of the LoginRadiusAuth class in the social-auth-core package. Specifically, the class set the class-level variable REDIRECT_STATE to False and STATE_PARAMETER to False. The underlying social-core engine uses these variables to determine whether to perform anti-CSRF token verification during the OAuth callback phase. By setting REDIRECT_STATE to False, the developer configuration explicitly disabled the built-in state verification mechanisms.

In standard OAuth 2.0 flows, the state parameter is generated dynamically prior to redirecting the user to the provider. The value is stored in the user's session. When the provider redirects the user back to the application's callback URL, the application checks the URL parameter named state against the value in the active session. If the two values do not match, the authentication flow is terminated immediately to prevent session hijacking and CSRF.

Without these safeguards in the LoginRadius backend, the application callback endpoint blindly accepts authentication tokens provided in the URL query parameters. This architectural design decision allowed authentication callback requests to be replayed or submitted across domains without validating the original state of the initiating browser session. Consequently, any active session could be targeted to complete an authentication loop using an arbitrary third-party token.

The vulnerable implementation of LoginRadiusAuth in social_core/backends/loginradius.py did not implement any code path for state generation or validation. The auth_html method, which is responsible for initiating the authentication flow and rendering the redirection target, generated a callback URI without injecting a state variable. The following code snippet demonstrates the vulnerable class definition before the remediation patch:

class LoginRadiusAuth(BaseOAuth2):
    # ...
    ID_KEY = "ID"
    ACCESS_TOKEN_URL = "https://api.loginradius.com/api/v2/access_token"
    PROFILE_URL = "https://api.loginradius.com/api/v2/userprofile"
    REDIRECT_STATE = False    # Vulnerable: State generation and validation disabled
    STATE_PARAMETER = False
 
    def uses_redirect(self) -> bool:
        return False
 
    def auth_html(self):
        key, _secret = self.get_key_and_secret()
        tpl = self.setting("TEMPLATE", "loginradius.html")
        return self.strategy.render_html(
            tpl=tpl,
            context={
                "backend": self,
                "LOGINRADIUS_KEY": key,
                "LOGINRADIUS_REDIRECT_URL": self.get_redirect_uri(), # Vulnerable: No state token is passed
            },
        )

The patch committed under SHA 4d332820e6b0583fde522956105a0e2beced5335 resolves this issue by modifying the class variable REDIRECT_STATE = True and updating the authentication initiation logic. The auth_html method now obtains or generates a state token via self.get_or_create_state() and passes it to both the template context and the get_redirect_uri function. The patched code is shown below:

class LoginRadiusAuth(BaseOAuth2):
    # ...
    ID_KEY = "ID"
    ACCESS_TOKEN_URL = "https://api.loginradius.com/api/v2/access_token"
    PROFILE_URL = "https://api.loginradius.com/api/v2/userprofile"
    REDIRECT_STATE = True     # Patched: Enables state validation
    STATE_PARAMETER = False
 
    def uses_redirect(self) -> bool:
        return False
 
    def auth_html(self):
        key, _secret = self.get_key_and_secret()
        state = self.get_or_create_state() # Patched: Generates and registers state token
        tpl = self.setting("TEMPLATE", "loginradius.html")
        return self.strategy.render_html(
            tpl=tpl,
            context={
                "backend": self,
                "LOGINRADIUS_KEY": key,
                "LOGINRADIUS_REDIRECT_STATE": state,
                "LOGINRADIUS_REDIRECT_URL": self.get_redirect_uri(state), # Patched: Appends state to callback URI
            },
        )

This code-level change ensures that when the browser requests the LoginRadius callback endpoint, the engine demands a matching redirect_state parameter. The validation logic is delegated to the core class implementation, which throws an exception if the parameter is missing or mismatched.

Exploitation of CVE-2026-57177 requires the attacker to construct a valid third-party authentication payload and force the victim's browser to submit it to the application's callback endpoint. The target application must have the LoginRadius authentication backend enabled. The attacker begins by initiating the authentication process against the target application using their own LoginRadius credentials. The attacker intercepts the redirection response from LoginRadius containing the login token.

Instead of completing the login flow within their own browser, the attacker extracts the token parameter from the redirected callback URL. This token is associated with the attacker's LoginRadius identity and remains valid for a limited period. The attacker then constructs a malicious payload, such as an invisible img element or an iframe, hosted on a website controlled by the attacker or injected via HTML injection into a trusted site.

<!-- Malicious cross-site request targeting the victim's session -->
<img src="https://target-app.example/complete/loginradius/?token=ATTACKER_TOKEN_HERE" style="display:none;" />

When the victim visits the attacker-controlled webpage, the victim's browser automatically submits the HTTP request to the target application's callback endpoint. Because the target application does not validate the state parameter on the callback, the framework processes the attacker's token. The victim's application session is subsequently mapped to the attacker's external LoginRadius identity. If the target application supports account linking, the attacker's third-party login credentials become persistently bound to the victim's local account.

The primary consequence of this Login CSRF vulnerability is unauthorized session manipulation and persistent identity linking. Once an attacker successfully binds their LoginRadius identity to the victim's application account, the attacker can log into the victim's account at any time by executing a standard OAuth login using the bound LoginRadius profile. This bypasses authentication controls and provides full, persistent access to the victim's data and privileges within the application.

In scenarios where the victim is already logged into the application, the injection of the attacker's token associates the victim's active session with the attacker's account. Any sensitive actions performed by the victim, such as entering payment information, saving personal documents, or submitting sensitive queries, will be saved under the attacker's account history. The attacker can then view these transactions by logging into their own account.

The CVSS v3.1 score of 4.3 is characterized by low complexity (AC:L) and network accessibility (AV:N), with user interaction (UI:R) required. While confidentiality impacts are evaluated as low to none initially, the logical downstream impact of identity binding represents a critical threat to user privacy and data integrity. Applications utilizing the LoginRadius backend must treat this as a high-risk security flaw.

The primary resolution is to upgrade the social-auth-core dependency to version 5.0.0 or higher. The package update implements the robust validation of the state parameter in the LoginRadius backend module and addresses unit test coverage to prevent regression. Administrators can upgrade the package using Python package management utilities.

pip install --upgrade social-auth-core>=5.0.0

If immediate software upgrade is unfeasible, administrators must disable the LoginRadius authentication backend. In Django applications, this involves removing the specific backend path from the AUTHENTICATION_BACKENDS setting in the project configuration files. Applications must verify that no other custom OAuth backends have REDIRECT_STATE set to False unless there is a specific, secure alternative state management mechanism in place.

# settings.py modification
AUTHENTICATION_BACKENDS = (
    # Disable the vulnerable backend immediately if upgrading is not possible
    # 'social_core.backends.loginradius.LoginRadiusAuth',
    'social_core.backends.google.GoogleOAuth2',
    'django.contrib.auth.backends.ModelBackend',
)

To ensure defense-in-depth, security teams should configure session cookies with appropriate flags. Setting SameSite=Lax or SameSite=Strict on session cookies ensures that web browsers will omit credentials from third-party requests, significantly lowering the exploitability of cross-site request forgery attacks on endpoints that rely on cookie-based authentication sessions.