提交 #811279: litellm <= 1.63.1 Improper Authorization (CWE-285)

# Technical Details
A Privilege Escalation vulnerability exists in the `block_key` and `unblock_key` methods in `litellm/proxy/management_endpoints/key_management_endpoints.py` of litellm.

The application fails to restrict access to key management operations. The endpoints `/key/block` and `/key/unblock` implicitly grant access to any user with the `internal_user` role instead of enforcing ownership checks or limiting operations to `proxy_admin` level accounts.

# Vulnerable Code
File: `litellm/proxy/management_endpoints/key_management_endpoints.py`
Method: `block_key`, `unblock_key`
Why: The API routes for key blocking/unblocking are included in `internal_user_routes`. Inside the actual logic, no verification is done to determine if the target key being disabled/enabled belongs to the requesting user or if the requesting user possesses administrative privileges.

# Reproduction
1. Establish a LiteLLM proxy instance and obtain an `internal_user` API key (`<ATTACKER_KEY>`).
2. Identify or guess an existing key belonging to another user, potentially an administrator.
3. Send a POST request to block the target key using the lower-privileged token: `curl -X POST "http://localhost:4000/key/block" -H "Authorization: Bearer <ATTACKER_KEY>" -H "Content-Type: application/json" -d '{"key": "<ADMIN_KEY>"}'`
4. The target key is disabled, denying its owner access to the proxy. The attacker can identically unblock it later.

# Impact
- Denial of Service (DoS) against administrative or production systems by disabling valid keys.
- Privilege Escalation, allowing a regular internal user to manipulate system-wide access without adequate auditing.

• 来源: ⚠️ https://gist.github.com/YLChen-007/993c68152b2c770d53590f1684c755d4
• 用户: Eric-c (UID 96848)
• 提交: 2026-04-23 09時55分 (5 月前)
• 管理: 2026-06-20 11時26分 (2 months later)
• 状态: 已接受
• VulDB条目: 372512 [BerriAI litellm 直到 1.63.1 Admin Key key_management_endpoints.py 权限提升]
• 积分: 20