Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

الخلاصاتاتصالالخصوصية© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
cve-2026-93355-lab — إعادة إنتاج غير ضارة وغير متصلة بالإنترنت لـ CVE-2026-93355 — استيلاء على الحساب عبر JWT بالبريد الإلكتروني غير المُتحقَّق منه في LiteLLM (يشغّل الشيفرة الحقيقية لـ LiteLLM) | Kitploit
أدوات/GitHubGitHub/inertfluid/cve-2026-93355-lab
تصعيد الامتيازاتتحليل الثغرات الأمنيةاستغلال تطبيقات الويبإدارة الهوية والوصول (IAM)المصادقةالأوراق والأبحاثالتعلم والتعليممختبرات وتدريب عملي
GitHubinertfluid/cve-2026-93355-lab

cve-2026-93355-lab

إعادة إنتاج غير ضارة وغير متصلة بالإنترنت لـ CVE-2026-93355 — استيلاء على الحساب عبر JWT بالبريد الإلكتروني غير المُتحقَّق منه في LiteLLM (يشغّل الشيفرة الحقيقية لـ LiteLLM)

منذ شهر واحدلم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة
عرض المستودع

CVE-2026-93355 — مختبر استيلاء على الحساب عبر JWT بالبريد الإلكتروني غير المُتحقَّق منه في LiteLLM

مختبر مكتفٍ ذاتيًا وقابل للتخلص منه يعيد إنتاج CVE-2026-93355: مصادقة JWT في LiteLLM تحدد هوية المستدعي بالرجوع إلى مطابقة البريد الإلكتروني — ولا تتحقق أبدًا من ادعاء email_verified. فالمهاجم الذي يستطيع جعل حساب مزوّد الهوية الخاص به يُصدر رمزًا موقّعًا بشكل صالح يحمل عنوان بريد إلكتروني للضحية (غير مُتحقَّق منه) يرث دور الضحية، وصولًا إلى proxy_admin، كما أن المطابقة تعيد كتابة ارتباط SSO المخزَّن للضحية بصمت لتحل محلّه هوية المهاجم، مما يجعل الاستيلاء دائمًا.

التنبيه الأمنيVulnCheck · OX Security
CVECVE-2026-93355
المشروعlitellm (الوكيل / مصادقة JWT)
المتأثر≤ 1.102.1 وفقًا للتنبيه الأمني — لا يزال دون إصلاح: الكود الثغرة لم يتغير في 1.104.0 (أحدث إصدار مستقر) وفي main حتى 2026-10-07
CVSS8.1 HIGH (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N)
الضعفCWE-1390 — مصادقة ضعيفة
السبب الجذريالبحث عن المستخدم بالبريد الإلكتروني يُوثَق به دون التحقق من email_verified
الاكتشافNir Zadok وMoshe Siman Tov Bustan (OX Security)

حالة الإصلاح (2026-10-07): لا يوجد إصدار مُصلَح بعد. يُدرج التنبيه الأمني 1.102.1 فقط لأنه كان أحدث إصدار وقت الإفصاح؛ وقد أصدر LiteLLM منذ ذلك الحين 1.103.x و1.104.0، ولا تزال الدالة _get_fuzzy_user_object في كليهما — وعلى main — بلا أي تحقق من email_verified. يثبّت المختبر 1.102.1 لأغراض قابلية إعادة الإنتاج؛ وسينبّه scripts/verify_against_real_source.py في اليوم الذي يُطرح فيه إصلاح.

⚠️ الاستخدام الأخلاقي

يعيد هذا إنتاج ثغرة مُفصَح عنها علنًا لأغراض تعليمية ودفاعية. يعمل محليًا بالكامل ولا يمس أي خدمة حقيقية:

  • لا يوجد خروج للشبكة. "مزوّد الهوية" هو محاكاة داخل العملية تُصدر JWT حقيقيًا موقّعًا بـ RS256 من زوج مفاتيح مؤقت. و"قاعدة البيانات" هي قائمة Python.
  • الاستغلال غير ضار: يحل صفًا إداريًا وهميًا مزروعًا [email protected] داخل هذه العملية ويطبعه. لا يوجد حساب حقيقي، ولا مفتاح حقيقي، ولا شيء يغادر جهازك.
  • لا توجّه هذه التقنية أبدًا إلى مزوّد هوية أو مستأجر أو نشر LiteLLM لا تملكه ولا تملك إذنًا باختباره.

الثغرة في فقرة واحدة

يتيح وكيل LiteLLM المصادقة باستخدام JWT من مزوّد الهوية المُهيَّأ لديك. ولربط ذلك الرمز بمستخدم LiteLLM يستدعي get_user_object()، التي تحاول أولًا مطابقة موضوع الرمز (sso_user_id)، وعند الفشل ترجع إلى _get_fuzzy_user_object() — وهي مطابقة غير حساسة لحالة الأحرف على ادعاء email. من يملك ذلك البريد الإلكتروني في جدول LiteLLM هو من تصبح هويته. ادعاء email_verified في الرمز لا يُقرأ أبدًا — لا أثناء استخراج الادعاءات (JWTHandler.get_user_email) ولا أثناء الحل. لذا فإن أي مزوّد هوية يُصدر رمزًا لبريد إلكتروني غير مُتحقَّق منه (معظمهم يفعل ذلك بحكم التصميم — فالتحقق هو مسؤولية الطرف المعتمد) يتيح للمهاجم تعيين بريد ملفه الشخصي إلى بريد الضحية، وتقديم الرمز، ووراثة دور الضحية. والأسوأ من ذلك، عند مطابقة البريد الإلكتروني يُطلق LiteLLM مهمة خلفية تستبدل sso_user_id الخاص بالضحية بموضوع المهاجم — لذا فإن كل تسجيل دخول لاحق يُحل مباشرة إلى حساب الضحية دون الحاجة إلى البريد الإلكتروني، ولا يفيد تغيير البريد الإلكتروني.

مسار الهجوم: النسخة الثغرة مقابل النسخة المُصلَحة

ما يثبته هذا المختبر — وكيف يبقى صادقًا

كل ما يخضع للاختبار هو كود LiteLLM نفسه، مستوردًا من حزمة litellm==1.102.1 المثبَّتة. لا يوفّر المختبر سوى أمرين لا بد منهما: جدول مستخدمين وهمي في الذاكرة وزوج مفاتيح مزوّد هوية محاكى. وهو لا يعيد تنفيذ المنطق الثغرة.

  1. الحقيقة المرجعية. نستخدم inspect.getsource() على _get_fuzzy_user_object وJWTHandler.get_user_email المثبّتتين ونتحقق من وجود آلية الرجوع إلى البريد الإلكتروني، ومن وجود إعادة ربط sso_user_id، ومن أن أيًا من الدالتين لا تشير إلى email_verified. → scripts/verify_against_real_source.py
  2. الاستيلاء على الحساب. يُمرَّر رمز صالح يحمل بريدًا إلكترونيًا غير مُتحقَّق منه لضحية عبر استخراج المطالبات الحقيقي في LiteLLM و_get_fuzzy_user_object الحقيقية؛ فيُحلّ إلى صف proxy_admin الخاص بالضحية. → poc/01_account_takeover.py
  3. الاستمرارية. تعيد الكتابة الخلفية لمطابقة البريد الإلكتروني ربط sso_user_id الخاص بالضحية بمعرّف المهاجم (subject)؛ وعند تسجيل دخول لاحق دون أي بريد إلكتروني على الإطلاق يُحلّ مباشرةً إلى المسؤول، ولا يؤدي "إصلاح البريد الإلكتروني المكرر" إلى إبطال ذلك. → poc/02_persistent_rebind.py
  4. الإصلاح. إن فرض email_verified قبل الرجوع إلى البريد الإلكتروني يمنع الهجوم مع إبقاء عمليات تسجيل الدخول عبر SSO المُتحقَّق منها تعمل. → poc/03_patched_path.py

تشغيله

./run.sh

run.sh يبني .venv مؤقتًا، ويثبّت litellm[proxy]==1.102.1، ويشغّل فحص الحقيقة الأساسية، ثم جميع PoCs الثلاثة. أول تشغيل يقوم بتنزيل LiteLLM ويستغرق بضع دقائق؛ احذف .venv للتنظيف. لاستخدام مفسّر موجود مسبقًا: PYTHON=python3.12 ./run.sh.

شغّل PoC واحدًا مباشرةً (داخل الـ venv):

.venv/bin/python poc/01_account_takeover.py

التخطيط

cve-2026-93355-lab/
├── mock_idp.py                        # ephemeral RS256 OIDC IdP (real signatures)
├── fake_litellm_db.py                 # in-memory stand-in for the Prisma user table
├── harness.py                         # configures & drives LiteLLM's real objects
├── poc/
│   ├── 01_account_takeover.py         # unverified email -> victim's proxy_admin
│   ├── 02_persistent_rebind.py        # sso_user_id overwrite -> persistent access
│   └── 03_patched_path.py             # the email_verified guard that closes it
├── scripts/
│   └── verify_against_real_source.py  # proves the PoCs run the real vulnerable code
├── assets/attack-flow.svg|.png        # the diagram above
├── blog-cve-2026-93355.md             # the guard0 write-up
└── run.sh

المعالجة

  • الترقية بمجرد أن يصدر LiteLLM إصلاحًا، وتتبّع الاستشارة.
  • فرض email_verified: true عند حدود الثقة قبل أن يصل أي رمز إلى عملية تحديد الهوية؛ ارفض أو تجاهل رسائل البريد الإلكتروني غير المُتحقَّق منها.
  • اربط الهوية بمعرّف موضوعي مستقر يصدره المزوّد (user_id_jwt_field)، وليس ببريد إلكتروني قابل للتغيير، ولا تدع الاحتياطي المعتمد على البريد الإلكتروني يعيد ربطها بصمت.
  • لا تُزوّد الأدوار ذات الامتيازات مسبقًا بالاعتماد على البريد الإلكتروني وحده. فسجل proxy_admin المرتبط بالبريد الإلكتروني يُعدّ بدائية استيلاء دائمة.

المراجع

  1. CVE-2026-93355 (NVD) — https://nvd.nist.gov/vuln/detail/CVE-2026-93355
  2. VulnCheck advisory — https://www.vulncheck.com/advisories/litellm-weak-jwt-authentication-via-email-based-user-lookup
  3. OX Security write-up — https://www.ox.security/blog/litellm-an-ordinary-login-token-can-become-someone-elses-admin-account/
  4. LiteLLM — https://github.com/BerriAI/litellm
تنزيل الأداة