هجوم سلسلة التوريد على LiteLLM: جرس إنذار لأمن البنية التحتية للذكاء الاصطناعي
في 24 مارس 2026، تم نشر نسختين خبيثتين من حزمة Python LiteLLM على منصة PyPI. في غضون 40 دقيقة فقط، تم تحميل برنامج خبيث لسرقة بيانات الاعتماد من قبل آلاف أنابيب CI/CD حول العالم. إليكم تحليلاً معمقاً لهجوم يكشف هشاشة سلسلة التوريد البرمجية للذكاء الاصطناعي.
LiteLLM: حلقة حرجة في البنية التحتية للذكاء الاصطناعي
LiteLLM هي مكتبة Python مفتوحة المصدر توحّد استدعاءات واجهات برمجة التطبيقات لأكثر من 100 مزود لنماذج اللغة (OpenAI وAnthropic وAzure وAWS Bedrock وغيرها) عبر واجهة واحدة. مع 97 مليون تحميل شهرياً وتواجد مقدّر في 36% من البيئات السحابية، أصبحت LiteLLM مكوناً أساسياً في العديد من بنيات الذكاء الاصطناعي في الإنتاج.
هذه الشعبية الواسعة تجعلها هدفاً مثالياً للمهاجمين.
الجدول الزمني للهجوم
كان اختراق LiteLLM جزءاً من حملة أوسع نفذتها مجموعة TeamPCP:
- أواخر فبراير 2026: الاختراق الأولي لمستودع Trivy (أداة فحص الثغرات من Aqua Security)
- 19 مارس: موجة اختراق Trivy عبر بيانات اعتماد CI مسروقة
- 21 مارس: تسميم علامات GitHub Action لأداة KICS
- 24 مارس، 10:39 UTC: نشر النسخ الخبيثة
litellm==1.82.7وlitellm==1.82.8على PyPI - 24 مارس، ~11:19 UTC: عزل الحزم بعد حوالي 40 دقيقة
- 27 مارس: اختراق SDK Python الخاص بـ Telnyx من نفس المجموعة
- 30 مارس: إصدار النسخة النظيفة
1.83.0عبر أنبوب CI/CD أُعيد بناؤه بالكامل
التشريح التقني للبرنامج الخبيث
احتوت النسخ المخترقة على حمولتين خبيثتين:
ملف .pth (النسخة 1.82.8)
تم إسقاط ملف باسم litellm_init.pth في مجلد site-packages. تتميز ملفات .pth بخاصية خطيرة: يتم تنفيذها تلقائياً عند كل بدء تشغيل لمفسر Python. استخدم البرنامج الخبيث subprocess.Popen لإطلاق عمليات جمع البيانات.
من المفارقات أن التنفيذ احتوى على خطأ قاتل. كل عملية فرعية كانت تشغّل نفس ملف .pth، مما أدى إلى إنشاء قنبلة تفرّع أسية أشبعت المعالج بنسبة 100%. هذا السلوك بالتحديد هو ما أدى إلى اكتشاف الهجوم بسرعة — لاحظ الباحث Callum McMahon أن جهازه "يتعثر بشدة" مع استغراق htop عشرات الثواني للتحميل.
خادم الوكيل المعدّل (النسختان 1.82.7 و1.82.8)
احتوى ملف proxy_server.py المعدّل على كود مصمم لـ:
- جمع متغيرات البيئة (مفاتيح API، رموز السحابة)
- استخراج مفاتيح SSH وبيانات اعتماد Git
- سرقة رموز Kubernetes وكلمات مرور قواعد البيانات
- جمع بيانات اعتماد AWS وGCP وAzure
- تهريب البيانات عبر طلبات POST مشفرة إلى
models.litellm[.]cloud، وهو نطاق يسيطر عليه المهاجمون
تأثير الدومينو: من Trivy إلى Mercor
يوضح الهجوم بشكل مثالي المخاطر المتسلسلة في سلاسل التوريد البرمجية الحديثة:
- يتم اختراق Trivy (أداة فحص أمني)
- بيانات اعتماد CI/CD المسروقة عبر Trivy تمنح الوصول إلى أنبوب نشر LiteLLM
- نسخ LiteLLM الخبيثة تصيب آلاف البيئات في المراحل اللاحقة
- Mercor، شركة ناشئة للتوظيف بالذكاء الاصطناعي، تؤكد تأثرها في 2 أبريل 2026
تدّعي مجموعة الابتزاز Lapsus$ امتلاك 4 تيرابايت من بيانات Mercor، تشمل ملفات المرشحين والبيانات الشخصية والكود المصدري ومفاتيح API وتسجيلات مقابلات الفيديو. يتم عرض هذه البيانات للبيع في منتديات سرية.
من كان معرّضاً فعلاً؟
وفقاً لتحليل LiteLLM بعد الحادث، المستخدمون المتأثرون هم من:
- قاموا بتثبيت أو تحديث LiteLLM عبر
pipيوم 24 مارس بين 10:39 و16:00 UTC - استخدموا تبعيات غير مثبّتة الإصدار (بدون نسخة محددة في
requirements.txt) - شغّلوا أنابيب CI/CD تثبّت تلقائياً أحدث إصدارات الحزم
مستخدمو صورة Docker الرسمية لوكيل LiteLLM لم يتأثروا، لأن التبعيات مثبّتة الإصدار في ملف requirements.txt.
دروس لتأمين تبعيات الذكاء الاصطناعي
يسلط هذا الهجوم الضوء على ممارسات أساسية غالباً ما يتم تجاهلها في منظومة الذكاء الاصطناعي:
1. ثبّت إصدارات تبعياتك
# ممارسة سيئة
litellm
# ممارسة جيدة
litellm==1.82.6لا تدع pip install يجلب أحدث إصدار بدون رقابة. استخدم ملف requirements.txt بإصدارات دقيقة وتحقق من بصمات SHA-256.
2. استخدم سجلاً خاصاً أو وكيل حزم
أدوات مثل Artifactory وNexus وAWS CodeArtifact تتيح لك تصفية وفحص الحزم قبل وصولها إلى بيئاتك. قم بتكوين سياسات الاحتفاظ والتحقق التلقائي.
3. راجع أنبوب CI/CD الخاص بك
- اعزل مشغّلات CI بوصول شبكي مقيّد
- استخدم بيانات اعتماد مؤقتة بدلاً من رموز طويلة الأمد
- فعّل المصادقة متعددة العوامل على جميع حسابات النشر (PyPI وnpm وغيرها)
- راقب الاتصالات الصادرة غير المعتادة من أنابيبك
4. حافظ على قائمة مكونات البرنامج (SBOM)
أنشئ وحافظ على جرد كامل لتبعياتك باستخدام أدوات مثل Syft أو CycloneDX. في حالة وقوع حادث، يمكنك تحديد المكونات المتأثرة بسرعة.
5. راقب سلوك الشبكة في الإنتاج
البرنامج الخبيث في LiteLLM كان يهرّب البيانات إلى نطاق غير رسمي. مراقبة الاتصالات الصادرة كانت ستطلق تنبيهاً فورياً. حلول مثل Falco أو Tracee تكشف هذا النوع من السلوك غير الطبيعي أثناء التشغيل.
سطح الهجوم المتنامي للذكاء الاصطناعي
تعتمد منظومة الذكاء الاصطناعي على تراكم من التبعيات مفتوحة المصدر نادراً ما يتم تدقيقها بالدقة المطلوبة. LiteLLM مجرد مثال واحد — حزم SDK الخاصة بالمزودين، وأطر تنسيق الوكلاء، ومكتبات قواعد البيانات المتجهية — كل منها يمثل ناقل هجوم محتمل.
مع التبني الواسع للوكلاء الذكاء الاصطناعي المستقلين في المؤسسات، فإن عواقب اختراق سلسلة التوريد لم تعد تقتصر على سرقة الكود. وكيل مخترق يمكنه:
- الوصول إلى الأنظمة الداخلية عبر بيانات اعتماد مسروقة
- تعديل كود الإنتاج بدون إشراف بشري
- تهريب بيانات أعمال حساسة
الإجراءات الفورية الموصى بها
إذا كنت تستخدم LiteLLM في مشاريعك، إليك الخطوات الواجب اتخاذها:
- تحقق مما إذا تم تثبيت
litellm==1.82.7أو1.82.8في بيئاتك - ابحث عن ملف
litellm_init.pthفي مجلداتsite-packages - احجب حركة المرور الصادرة إلى
models.litellm[.]cloudوcheckmarx[.]zone - قم بتدوير جميع أسرارك: مفاتيح API، رموز السحابة، مفاتيح SSH، بيانات اعتماد قواعد البيانات
- حدّث إلى
litellm>=1.83.0الذي تم إصداره عبر أنبوب CI/CD أُعيد بناؤه بالكامل
الخلاصة
هجوم LiteLLM هو جرس إنذار لكل مؤسسة تبني بالذكاء الاصطناعي. أمن سلسلة التوريد البرمجية لم يعد موضوعاً محصوراً بفرق DevSecOps — إنه تحدٍ استراتيجي يخص كل مطور ومهندس ومسؤول تقني.
في منظومة حيث حزمة PyPI مخترقة لمدة 40 دقيقة يمكنها التأثير على آلاف الشركات، لم تعد الثقة العمياء في التبعيات مفتوحة المصدر خياراً مقبولاً.
ناقش مشروعك معنا
نحن هنا للمساعدة في احتياجات تطوير الويب الخاصة بك. حدد موعدًا لمناقشة مشروعك وكيف يمكننا مساعدتك.
دعنا نجد أفضل الحلول لاحتياجاتك.