GitHub Security Advisory: GHSA-5j53-63w8-8625
Package: fastapi-users (PIP)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-285: Improper Authorization, CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: < 15.0.2
Patched in: 15.0.2

Summary: FastAPI Users Vulnerable to 1-click Account Takeover in Apps Using FastAPI SSO

Details:
**Description**

The OAuth login state tokens are completely stateless and carry no per-request entropy or any data that could link them to the session that initiated the OAuth flow. `generate_state_token()` is always called with an empty `state_data` dict, so the resulting JWT only contains the fixed audience claim plus an expiration timestamp. \[1\]

```py
        state_data: dict[str, str] = {}
        state = generate_state_token(state_data, state_secret)
        authorization_url = await oauth_client.get_authorization_url(
            authorize_redirect_url,
            state,
            scopes,
        )
```

*fastapi\_users/router/oauth.py:65-71*

On callback, the library merely checks that the JWT verifies under `state_secret` and is unexpired; there is no attempt to match the state value to the browser that initiated the OAuth request, no correlation cookie, and no server-side cache. \[2\]

```py
        try:
            decode_jwt(state, state_secret, [STATE_TOKEN_AUDIENCE])
        except jwt.DecodeError:
            raise HTTPException(
                status_code=status.HTTP_400_BAD_REQUEST,
                detail=ErrorCode.ACCESS_TOKEN_DECODE_ERROR,
            )
        except jwt.ExpiredSignatureError:
            raise HTTPException(
                status_code=status.HTTP_400_BAD_REQUEST,
                detail=ErrorCode.ACCESS_TOKEN_ALREADY_EXPIRED,
            )
```

*fastapi\_users/router/oauth.py:130-141*

Any attacker can hit `/authorize`, capture the server-generated state, finish the upstream OAuth flow with their own provider account, and then trick a victim into loading `.../callback?code=<attacker_code>&state=<attacker_state>`. Because the state JWT is valid for any client for \~1 hour, the victim’s browser will complete the flow. This leads to login CSRF. Depending on the app’s logic, the login CSRF can lead to an account takeover of the victim account or to the victim user getting logged in to the attacker's account.

\[1\] [https://github.com/fastapi-users/fastapi-users/blob/bcee8c9b884de31decb5d799aead3974a0b5b158/fastapi\_users/router/oauth.py\#L57](https://github.com/fastapi-users/fastapi-users/blob/bcee8c9b884de31decb5d799aead3974a0b5b158/fastapi_users/router/oauth.py#L57)

\[2\]  
[https://github.com/fastapi-users/fastapi-users/blob/bcee8c9b884de31decb5d799aead3974a0b5b158/fastapi\_users/router/oauth.py\#L111](https://github.com/fastapi-users/fastapi-users/blob/bcee8c9b884de31decb5d799aead3974a0b5b158/fastapi_users/router/oauth.py#L111)

**Proof of Concept**

Let’s think of an app \- AwesomeFastAPIApp. Let’s assume that the AwesomeFastAPIApp has internal logic that uses a `UserManager` different from the default `BaseUserManager.` With this `manager,` when an already logged-in user performs a callback request,  the newly provided SSO identity gets linked to the already existing user that made the request.

Then, an attacker can get account takeover inside the app by performing the following actions:

1\. They