[Bug]: Internal Users able to generate keys using other user's user_id (Vulnerability)

[mirodrr2]

What happened?

It seems like non admin users are able to generate keys using other user's user_id.

The following works:

Request

curl -X POST "https://<DeploymentUrl>/user/new" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <Admin or Master Key>" \
-d '{
     "user_id": "[email protected]",
     "user_email": "[email protected]",
     "user_role": "internal_user"
}'

Response

{"key_alias":null,"duration":null,"models":[],"spend":0.0,"max_budget":1000000000.0,"user_id":"[email protected]","team_id":null,"max_parallel_requests":null,"metadata":{},"tpm_limit":null,"rpm_limit":null,"budget_duration":"1mo","allowed_cache_controls":[],"soft_budget":null,"config":{},"permissions":{},"model_max_budget":{},"send_invite_email":null,"model_rpm_limit":null,"model_tpm_limit":null,"guardrails":null,"blocked":null,"aliases":{},"key":"<New_User_Key>","key_name":null,"expires":null,"token_id":null,"user_email":"[email protected]","user_role":"internal_user","teams":null,"user_alias":null}

And now we use that key to try to create a key for a different user_id

Request

curl -X POST "https://<DeploymentUrl>/key/generate" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <New_User_Key>" \
-d '{
     "user_id": "[email protected]"
 }'

Response

{"key_alias":null,"duration":null,"models":[],"spend":0.0,"max_budget":null,"user_id":"[email protected]","team_id":null,"max_parallel_requests":null,"metadata":{},"tpm_limit":null,"rpm_limit":null,"budget_duration":null,"allowed_cache_controls":[],"soft_budget":null,"config":{},"permissions":{},"model_max_budget":{},"send_invite_email":null,"model_rpm_limit":null,"model_tpm_limit":null,"guardrails":null,"blocked":null,"aliases":{},"key":"<Second New Key>","key_name":"sk-...tSXg","expires":null,"token_id":"78ccab11279deabc5c7f8e0dd2d5faeae69a8e78938fce93e044710794976918"}

Unless I'm misunderstanding something here, this seems like a major security bug

Relevant log output

No response

Are you a ML Ops Team?

No

What LiteLLM version are you on ?

v1.55.0

Twitter / LinkedIn details

No response

[mirodrr2]

I am now pretty convinced this is a bug, because there is a check to make sure a non-admin user cannot delete another user's api keys, but there is not a similar check to make sure a user cannot create an api key using another user's user_id

chatgpt gave a pretty good summary, which I verified is accurate
https://chatgpt.com/share/67660996-edd0-8006-aff6-515de4a3cf51

Relevant code file: https://github.com/BerriAI/litellm/blob/main/litellm/proxy/management_endpoints/key_management_endpoints.py

[krrishdholakia]

investigating. thank you for this issue @mirodrr2

[krrishdholakia]

able to repro. working on a fix

[krrishdholakia]

this seems specific to the internal_user role, as internal users are allowed to create keys for themselves

[krrishdholakia]

Fixed