GHSA-5J53-63W8-8625
Vulnerability from github – Published: 2025-12-19 21:10 – Updated: 2025-12-20 05:46Description
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]
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]
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.
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 start an SSO OAuth flow, but stop it right before making the callback call to AwesomeFastAPIApp;
2. The attacker tricks a logged-in user (via phishing, a drive-by attack, etc.) to perform a GET request with the attacker's state value and grant code to the AwesomeFastAPIApp callback. Because the library doesn’t check whether the state token is linked to the session performing the callback, the callback is processed, the grant code is sent to the provider, and the account linking takes place.
After the GET request is performed, the attacker's SSO account is linked with the victim's AwesomeFastAPIApp account permanently.
Suggested Fix
Make the state a value tied to the session of the user that initiated the OAuth flow, as recommended by the official RFC. [3]
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "fastapi-users"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "15.0.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68481"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-352"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-19T21:10:40Z",
"nvd_published_at": "2025-12-19T21:15:54Z",
"severity": "MODERATE"
},
"details": "**Description**\n\nThe 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\\]\n\n```py\n state_data: dict[str, str] = {}\n state = generate_state_token(state_data, state_secret)\n authorization_url = await oauth_client.get_authorization_url(\n authorize_redirect_url,\n state,\n scopes,\n )\n```\n\n*fastapi\\_users/router/oauth.py:65-71*\n\nOn 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\\]\n\n```py\n try:\n decode_jwt(state, state_secret, [STATE_TOKEN_AUDIENCE])\n except jwt.DecodeError:\n raise HTTPException(\n status_code=status.HTTP_400_BAD_REQUEST,\n detail=ErrorCode.ACCESS_TOKEN_DECODE_ERROR,\n )\n except jwt.ExpiredSignatureError:\n raise HTTPException(\n status_code=status.HTTP_400_BAD_REQUEST,\n detail=ErrorCode.ACCESS_TOKEN_ALREADY_EXPIRED,\n )\n```\n\n*fastapi\\_users/router/oauth.py:130-141*\n\nAny 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=\u003cattacker_code\u003e\u0026state=\u003cattacker_state\u003e`. Because the state JWT is valid for any client for \\~1 hour, the victim\u2019s browser will complete the flow. This leads to login CSRF. Depending on the app\u2019s 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\u0027s account.\n\n\\[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)\n\n\\[2\\] \n[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)\n\n**Proof of Concept**\n\nLet\u2019s think of an app \\- AwesomeFastAPIApp. Let\u2019s 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.\n\nThen, an attacker can get account takeover inside the app by performing the following actions:\n\n1\\. They start an SSO OAuth flow, but stop it right before making the callback call to AwesomeFastAPIApp; \n2\\. The attacker tricks a logged-in user (via phishing, a drive-by attack, etc.) to perform a GET request with the attacker\u0027s state value and grant code to the AwesomeFastAPIApp callback. Because the library doesn\u2019t check whether the state token is linked to the session performing the callback, the callback is processed, the grant code is sent to the provider, and the account linking takes place.\n\nAfter the GET request is performed, the attacker\u0027s SSO account is linked with the victim\u0027s AwesomeFastAPIApp account permanently.\n\n**Suggested Fix**\n\nMake the state a value tied to the session of the user that initiated the OAuth flow, as recommended by the official RFC. \\[3\\]\n\n\n\\[3\\] [https://www.rfc-editor.org/rfc/rfc6749\\#section-10.12](https://www.rfc-editor.org/rfc/rfc6749#section-10.12)",
"id": "GHSA-5j53-63w8-8625",
"modified": "2025-12-20T05:46:19Z",
"published": "2025-12-19T21:10:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fastapi-users/fastapi-users/security/advisories/GHSA-5j53-63w8-8625"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68481"
},
{
"type": "WEB",
"url": "https://github.com/fastapi-users/fastapi-users/commit/7cf413cd766b9cb0ab323ce424ddab2c0d235932"
},
{
"type": "PACKAGE",
"url": "https://github.com/fastapi-users/fastapi-users"
},
{
"type": "WEB",
"url": "https://github.com/fastapi-users/fastapi-users/blob/bcee8c9b884de31decb5d799aead3974a0b5b158/fastapi_users/router/oauth.py#L111"
},
{
"type": "WEB",
"url": "https://github.com/fastapi-users/fastapi-users/blob/bcee8c9b884de31decb5d799aead3974a0b5b158/fastapi_users/router/oauth.py#L57"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "FastAPI Users Vulnerable to 1-click Account Takeover in Apps Using FastAPI SSO"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.