BerriAI litellm M2M JWT user_api_key_auth.py improper authorization

An attacker who possesses a valid M2M JWT containing the `litellm_proxy_admin` scope can call any UI management endpoint (e.g., `/user/new`, `/team/new`, `/key/generate`) on a LiteLLM proxy that has `enable_jwt_auth: true` configured. The JWT authentication path does not enforce the same route-level restrictions that the OAuth2 path does, so the token is accepted as a `PROXY_ADMIN` for all routes [CWE-285]. The attack is remote, requires no prior authentication beyond the JWT itself, and is considered difficult due to the need to obtain or forge a valid M2M JWT with the admin scope [ref_id=1].

The vulnerability resides in `litellm/proxy/auth/user_api_key_auth.py`. The JWT M2M authentication block (lines 673–852) lacks a `RouteChecks.is_llm_api_route()` guard, allowing a JWT with the `litellm_proxy_admin` scope to return a `PROXY_ADMIN` role for **any** route, including management endpoints such as `/user/new`, `/team/new`, and `/key/generate`. In contrast, the OAuth2 M2M path (lines 641–668) correctly restricts access to LLM API and info routes only [ref_id=1].

The advisory does not provide a patch diff, but the fix would mirror the OAuth2 M2M guard already present at lines 641–647: before returning a `PROXY_ADMIN` auth object, the JWT path must check `RouteChecks.is_llm_api_route(route)` or `RouteChecks.is_info_route(route)` and reject management routes. Without this guard, any JWT with the `litellm_proxy_admin` scope is treated as a full admin for all endpoints, defeating the intended UI SSO separation [ref_id=1].