حدد باحثو الأمن ما يصفونه بأنه أكبر اختراق في سلسلة توريد الذكاء الاصطناعي تم كشفه حتى الآن في عام 2026، والأرقام المرتبطة به مذهلة. وفقًا لشركة استخبارات التهديدات CloudSEK، قد يكون الاختراق المرتبط بمشروع LiteLLM واسع الاستخدام قد طال أكثر من 2,500 شركة وما يقرب من 434,000 خط أنابيب CI/CD حول العالم. هذا الحجم وحده يجعل من هذه الحادثة واحدة من أكثر حوادث سلسلة توريد البرمجيات تأثيرًا على منظومة الذكاء الاصطناعي، ولا تزال تبعاتها قيد المعالجة بعد أشهر.
Summary
أهم النقاط
- تسرد مجموعة بيانات التعرض المعاد بناؤها من CloudSEK أكثر من 2,500 شركة و434,000 خط أنابيب CI/CD على أنها معرضة للاختراق بشكل محتمل.
- قامت مجموعة التهديد المعروفة باسم Team PCP بتنسيق الهجوم في مارس 2026 من خلال اختراق حزم LiteLLM على PyPI بالإصدارات 1.82.7 و1.82.8.
- كان نقطة الدخول الأولى هي أداة فحص الأمان Trivy المستخدمة داخل خط بناء LiteLLM، والتي ظلت مخترقة لمدة تقارب 20 يومًا.
- تشمل البيانات المسروقة وفقًا للتقارير مفاتيح سحابية، ورموز مستودعات، ومفاتيح SSH، وأسرار Kubernetes، وبيانات اعتماد نشر الحزم، ومتغيرات البيئة، ومفاتيح مزودي خدمات الذكاء الاصطناعي.
- أصدر مكتب التحقيقات الفيدرالي (FBI) تنبيه FLASH في يوليو 2026 محذرًا من أن بيانات الاعتماد المسروقة يمكن أن تُستخدم كسلاح في هجمات مستقبلية.
أكبر اختراق في سلسلة توريد الذكاء الاصطناعي لعام 2026 يكشف بيانات أكثر من 2,500 شركة
تشير تحقيقات CloudSEK إلى اختراق كبير بما يكفي لـالوصول إلى خطوط أنابيب البرمجيات لآلاف المؤسسات، العديد منها لم يكن لديه أي علاقة مباشرة مع المشروع المخترق سوى استخدامه كاعتمادية. هذه هي طبيعة سلاسل توريد البرمجيات الحديثة: حزمة واحدة مسمومة يمكن أن تُحدث موجات متتالية عبر عدد لا يحصى من الشركات غير المرتبطة ببعضها البعض.
المنظمات البارزة المذكورة في مجموعة بيانات التعرض
من بين المنظمات التي أشارت إليها CloudSEK كحالات تطابق عالية الثقة في مجموعة بيانات التعرض الخاصة بها: NVIDIA، وAmazon Web Services (AWS)، وCisco Systems، وSalesforce، وSiemens AG، وشركة X Corp (تويتر)، وOrange S.A.، إلى جانب عشرات المؤسسات العالمية الأخرى التي تمتد عبر قطاعات التمويل والاتصالات والتصنيع والدفاع. تشدد CloudSEK على أن “الثقة العالية” تعكس قوة أدلة التعرض، وليس دليلًا مؤكدًا على أن المنظمة قد تم اختراقها فعليًا أو أن البيانات قد سُرقت واستُخدمت. ومع ذلك، فإن مجرد ذكر اسم منظمة في مثل هذه المجموعة من البيانات يكفي لإطلاق مراجعة داخلية عاجلة، كما أن العديد من هذه المنظمات تدير بنى تحتية تشكل أساس أجزاء كبيرة من الإنترنت والحوسبة السحابية للمؤسسات.
تكتسب هذه القضية أهميتها لأن اختراقًا بهذا الحجم لا يؤثر فقط في خط إنتاج شركة واحدة — بل يمس بشكل محتمل بيانات الاعتماد وخطوط الأنابيب التي تربط حسابات السحابة وأنظمة التحكم في الشيفرة ومنصات البرمجيات كخدمة (SaaS) ومزودي خدمات الذكاء الاصطناعي المستخدمة عبر صناعات بأكملها.
كيف تطور الهجوم: من Trivy إلى LiteLLM
لم يبدأ الاختراق من LiteLLM نفسه، بل من أداة موثوقة كانت جزءًا من عملية بنائه. استولى المهاجمون على أداة فحص الأمان Trivy التي اعتمد عليها خط CI الخاص بـ LiteLLM، مستخدمين رمز أتمتة مسرّبًا كان قد تم تدويره لكن لم يُلغَ بالكامل. هذا الخلل ترك نافذة زمنية تقارب 20 يومًا تمكن خلالها المهاجمون من تنفيذ دفع قسري لشيفرة خبيثة فوق وسوم الإصدارات المنشورة لـ Trivy — شيفرة كانت لا تزال تبدو شرعية لأي طرف في السلسلة اللاحقة.
من هناك، تدفقت أداة الفحص المسمومة تلقائيًا إلى نظام البناء الخاص بـ LiteLLM، والذي قام بعد ذلك بإنتاج ونشر إصدارين مخترقين على فهرس حزم بايثون (PyPI): الإصداران 1.82.7 و1.82.8. وبحسب CloudSEK، ظلت هذه الحزم متاحة على PyPI لمدة تقارب 40 دقيقة — وهي نافذة ضيقة لكنها كانت كافية لإطلاق حدث تعرض عالمي، نظرًا لأن خطوط الأنابيب المؤتمتة تثبّت الاعتماديات بسرعة الآلة وغالبًا ما تعمل بصلاحيات نظام واسعة.
تم تنفيذ الشيفرة الخبيثة عبر ملف `.pth` يعمل تلقائيًا عند بدء تشغيل بايثون، ما يعني أنه لم يكن هناك حتى حاجة لاستيراد LiteLLM صراحةً لتفعيلها. سمحت هذه التفاصيل للحمولة بتجاوز العديد من آليات الحماية الشائعة في وقت التثبيت التي تعتمد عليها فرق الأمن.
ما الذي سرقه المهاجمون
بمجرد التشغيل، قامت البرمجية الخبيثة برفع الصلاحيات وجمع مجموعة واسعة من المواد الحساسة من الأنظمة المتأثرة. تشمل الفئات المبلغ عنها للبيانات المُهرَّبة ما يلي:
- بيانات اعتماد سحابية لـ AWS وGCP وAzure، إلى جانب رموز Kubernetes ومسارات حسابات الخدمة.
- رموز المستودعات، ومفاتيح SSH، وبيانات اعتماد نشر الحزم لمنصات التحكم في الشيفرة والسجلات.
- متغيرات البيئة وملفات `.env` التي تحتوي على أسرار التطبيقات.
- مفاتيح مزودي خدمات الذكاء الاصطناعي وبيانات تهيئة البوابات المرتبطة ببنى الذكاء الاصطناعي الأوسع لدى المؤسسات.
وفقًا لـ CloudSEK، تم تشفير البيانات المسروقة وفي بعض الحالات إرسالها إلى نطاق مُقلَّد (typosquatted)؛ وحيثما فشل الإخراج، يُقال إن البرمجية الخبيثة أنشأت مستودعًا عامًا داخل حساب GitHub الخاص بالضحية نفسه ورفعت البيانات المسروقة هناك كأصل لإصدار — ما يعني أن بعض المؤسسات ربما كانت تسرب أسرارها إلى العلن دون أن تدرك ذلك. وبما أن هذه البيانات الاعتمادية يمكن أن تصل إلى حسابات سحابية ومستودعات ومنصات SaaS وأنظمة مزودي خدمات الذكاء الاصطناعي، فإن العواقب العملية لهذا الاختراق في سلسلة توريد الذكاء الاصطناعي تمتد إلى ما هو أبعد بكثير من حزمة LiteLLM نفسها.
المخاطر المستمرة وما الذي سيحدث لاحقًا
لم ينتهِ التهديد هنا بمجرد سحب الحزم الخبيثة من PyPI. تظل بيانات الاعتماد المسروقة قابلة للاستخدام لأسابيع أو أشهر ما لم يتم تدويرها بنشاط، وهذا بالضبط ما دفع السلطات الفيدرالية إلى التدخل.
تحذير مكتب التحقيقات الفيدرالي وتدوير بيانات الاعتماد
أصدر مكتب التحقيقات الفيدرالي (FBI) تنبيه FLASH في يوليو 2026 (FLASH-20260702-01) محذرًا من أن الجهات المرتبطة بهذه الحملة من المرجح أن تستخدم بيانات الاعتماد المحصودة كسلاح بعد فترة طويلة من الاختراق الأصلي — وهو إشارة إلى أن هجمات سلسلة توريد إضافية ناتجة عن هذا الاختراق لا تزال احتمالًا حقيقيًا. هذا أحد الأسباب التي تجعل CloudSEK تؤكد أن تدوير مفتاح LiteLLM فقط أو بيانات اعتماد مزود نموذج واحد لا يكفي. يجب التعامل مع أي بيانات اعتماد يمكن للعملية المتأثرة قراءتها — سواء كانت مخزنة على القرص أو موجودة في الذاكرة أو مُحقنة في مهمة أو قابلة للاسترجاع عبر خدمة بيانات تعريف مثيل — على أنها معرضة للاختراق بشكل محتمل إلى أن يثبت العكس.
هذا الشرط الواسع لتدوير بيانات الاعتماد أصعب تنفيذًا مما يبدو. عمليًا، يعني ذلك أن فرق الأمن تحتاج إلى جرد كل بيانات اعتماد يمكن أن يكون خط أنابيب مخترق قد لمسها، وليس فقط تلك الواضحة المرتبطة بالحزمة المسمومة.
CloudSEK AIvigil ومراقبة بنية الذكاء الاصطناعي التحتية
تُقدّم CloudSEK هذا الحادث كدليل على أن بنية الذكاء الاصطناعي التحتية — البوابات، وبيئات تشغيل الوكلاء، وقواعد البيانات المتجهية، وخوادم MCP — أصبحت هدفًا استراتيجيًا عالي القيمة تحديدًا لأنها تقع عند تقاطع البيانات والهوية والعمل المؤتمت عبر المؤسسة. تم بناء منصة AIvigil الخاصة بها على هذا الأساس، حيث تراقب بنية الذكاء الاصطناعي التحتية بشكل مستمر لاكتشاف بيانات اعتماد مكشوفة، وأصول ذكاء اصطناعي ظلّية غير مُدارة، وتدفقات عمل وكيلة عالية المخاطر قبل أن تتحول إلى مسارات هجوم كاملة.
الدروس الأوسع التي يستخلصها الباحثون من هذه الحادثة هي أن اختراق أداة واحدة مرتبطة بالذكاء الاصطناعي — في هذه الحالة أداة فحص أمان تبعد ثلاث خطوات عن الهدف النهائي — يمكن أن يكشف شبكة كاملة من الهويات والأنظمة المترابطة. ومع تعمّق تضمين مكونات الذكاء الاصطناعي في عمليات التطوير والأعمال اليومية، يزداد نطاق الأضرار المحتملة لاختراق واحد في المنبع.
الأسئلة الشائعة
كم عدد الشركات التي تعرضت للاختراق بشكل محتمل في اختراق سلسلة توريد الذكاء الاصطناعي الخاص بـ LiteLLM؟
أكثر من 2,500 شركة تعرضت للاختراق بشكل محتمل، وفقًا لمجموعة بيانات التعرض المعاد بناؤها من CloudSEK.
ما أنواع بيانات الاعتماد التي سُرقت في هذا الاختراق؟
شملت بيانات الاعتماد المسروقة وفقًا للتقارير مفاتيح سحابية، ورموز مستودعات، ومفاتيح SSH، وأسرار Kubernetes، وبيانات اعتماد نشر الحزم، ومتغيرات البيئة، ومفاتيح مزودي خدمات الذكاء الاصطناعي.
كيف تمكن المهاجمون من اختراق حزم LiteLLM؟
اخترق المهاجمون أداة فحص الأمان الموثوقة Trivy المستخدمة في خط CI الخاص بـ LiteLLM وأدرجوا شيفرة خبيثة في حزم LiteLLM على PyPI بالإصدارات 1.82.7 و1.82.8.
ما الخطوات الموصى بها للمنظمات المتأثرة بهذا الاختراق؟
يُنصح المنظمات المتأثرة بتدوير جميع بيانات الاعتماد المكشوفة على نطاق واسع، وعزل الأنظمة المتأثرة، وإعادة بناء البيئات من مصادر نظيفة، ومراقبة سلوك وقت تشغيل CI/CD، ومراقبة بنية الذكاء الاصطناعي التحتية لديها بشكل مستمر في المستقبل.
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”كم عدد الشركات التي تعرضت للاختراق بشكل محتمل في اختراق سلسلة توريد الذكاء الاصطناعي الخاص بـ LiteLLM؟”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”أكثر من 2,500 شركة تعرضت للاختراق بشكل محتمل، وفقًا لمجموعة بيانات التعرض المعاد بناؤها من CloudSEK.”}},{“@type”:”Question”,”name”:”ما أنواع بيانات الاعتماد التي سُرقت في هذا الاختراق؟”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”شملت بيانات الاعتماد المسروقة وفقًا للتقارير مفاتيح سحابية، ورموز مستودعات، ومفاتيح SSH، وأسرار Kubernetes، وبيانات اعتماد نشر الحزم، ومتغيرات البيئة، ومفاتيح مزودي خدمات الذكاء الاصطناعي.”}},{“@type”:”Question”,”name”:”كيف تمكن المهاجمون من اختراق حزم LiteLLM؟”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”اخترق المهاجمون أداة فحص الأمان الموثوقة Trivy المستخدمة في خط CI الخاص بـ LiteLLM وأدرجوا شيفرة خبيثة في حزم LiteLLM على PyPI بالإصدارات 1.82.7 و1.82.8.”}},{“@type”:”Question”,”name”:”ما الخطوات الموصى بها للمنظمات المتأثرة بهذا الاختراق؟”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”يُنصح المنظمات المتأثرة بتدوير جميع بيانات الاعتماد المكشوفة على نطاق واسع، وعزل الأنظمة المتأثرة، وإعادة بناء البيئات من مصادر نظيفة، ومراقبة سلوك وقت تشغيل CI/CD، ومراقبة بنية الذكاء الاصطناعي التحتية لديها بشكل مستمر في المستقبل.”}}]}
تم إعداد هذه المقالة بمساعدة الذكاء الاصطناعي ومراجعتها من قبل الفريق التحريري.
