BerriAI litellm SSO Authentication Flow ui_sso.py get_redirect_response_from_openid session expiration
Description
A vulnerability was identified in BerriAI litellm up to 1.82.2. This impacts the function get_redirect_response_from_openid of the file litellm/proxy/management_endpoints/ui_sso.py of the component SSO Authentication Flow. The manipulation leads to session expiration. The attack is possible to be carried out remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1Patches
Vulnerability mechanics
Root cause
"The SSO login handler generates a new session token without deleting or invalidating previously issued tokens for the same user_id."
Attack vector
An attacker who obtains a user's SSO session token (via XSS, log exposure, network interception, or shoulder surfing) can retain access indefinitely because a new SSO login does not invalidate previously issued tokens [ref_id=1]. The victim's only self-service option—logging in again—leaves all old tokens active in the database. This allows the attacker to reuse a stolen token even after the legitimate user re-authenticates, effectively bypassing session rotation [CWE-613]. The attack is remote and requires no special privileges beyond possession of a historical token.
Affected code
The vulnerability is in `litellm/proxy/management_endpoints/ui_sso.py`, specifically the `get_redirect_response_from_openid` method of `SSOAuthenticationHandler` (lines ~2453–2542). The same missing-invalidation pattern also appears in the standard username/password login path at `litellm/proxy/auth/login_utils.py` (lines ~176–198) [ref_id=1].
What the fix does
The advisory does not include a patch diff. The recommended fix is to add a call inside `get_redirect_response_from_openid` that deletes, expires, or invalidates all previously issued verification tokens for the same `user_id` before or after generating the new key [ref_id=1]. Without this cleanup, every SSO login creates an additional valid token, and old tokens remain usable until their absolute expiration (default 24 hours). The same invalidation logic should be applied to the username/password login path in `login_utils.py` to close the gap system-wide.
Preconditions
- inputAttacker must have obtained a valid SSO session token for the victim (e.g., via XSS, log exposure, network interception, or shoulder surfing).
- configLiteLLM must be deployed with SSO configured (Google OAuth, Okta, or Generic OAuth).
- authThe victim must have logged in via SSO at least once, creating a token that the attacker can steal.
Reproduction
The public PoC script (`poc_exploit.py`) starts a mock OAuth server and LiteLLM proxy, performs two SSO logins for the same user, then queries the database to confirm both tokens remain active. It then uses Token 1 as a Bearer token on `/model/info` and confirms the request is authenticated, proving the old token was not invalidated [ref_id=1].
Generated on Jun 22, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
5- gist.github.com/YLChen-007/5fa8af12e1b183674d7ca96d852fb697mitreexploit
- vuldb.com/cve/CVE-2026-12796mitrethird-party-advisory
- vuldb.com/submit/811287mitrethird-party-advisory
- vuldb.com/vuln/372558mitrevdb-entrytechnical-description
- vuldb.com/vuln/372558/ctimitresignaturepermissions-required
News mentions
0No linked articles in our index yet.