BerriAI litellm SSO Debug Flow ui_sso.py json.dumps missing authentication

An unauthenticated attacker can reach `/sso/debug/login` (which redirects to the SSO provider) and then `/sso/debug/callback` to receive the OAuth user profile rendered in HTML [ref_id=1]. For Google/Microsoft SSO, raw `access_token` and `id_token` are also leaked, enabling token theft and impersonation against the identity provider [ref_id=1]. Additionally, because `json.dumps()` does not escape `<`, `>`, or `/`, an attacker who controls an IdP profile field (e.g., display name) can inject a `</script>` sequence and execute arbitrary JavaScript in the browser of anyone viewing the debug page, creating a reflected XSS vector [CWE-79] [ref_id=1].

The vulnerability resides in `litellm/proxy/management_endpoints/ui_sso.py`. The `/sso/debug/login` endpoint (line 3505) lacks the `Depends(user_api_key_auth)` dependency and only checks an enterprise license flag, while `/sso/debug/callback` (line 3555) has no authentication at all. The callback also passes `return_raw_sso_response=True` to Google and Microsoft SSO handlers (lines 3600–3611), bypassing the credential-filter allowlist, and injects OAuth data into a `<script>` block via `json.dumps()` without HTML escaping (lines 3650–3652).

The advisory does not include a published patch, but it identifies the root causes: the debug endpoints must require `Depends(user_api_key_auth)` to enforce authentication, the `return_raw_sso_response=True` flag should be removed or the `_OAUTH_TOKEN_FIELDS` allowlist applied, and the `json.dumps()` output must be HTML-escaped before being placed into the `<script>` block [ref_id=1]. Until a fix is released, the vendor recommends removing or disabling the SSO debug endpoints in production.

1. Verify unauthenticated access: `curl -s -o /dev/null -w "%{http_code}" http://localhost:4000/sso/debug/login` — expects 303 (not 401/403). 2. Verify unauthenticated callback: `curl -s -o /dev/null -w "%{http_code}" http://localhost:4000/sso/debug/callback` — expects 400 (not 401/403). 3. Complete the SSO debug flow by navigating to `http://localhost:4000/sso/debug/login` in a browser, authenticating with the SSO provider, and observing the rendered OAuth data including tokens for Google/Microsoft providers [ref_id=1].