⚡ أبرز النقاط

في مايو 2026، نشرت مجموعة TeamPCP أكثر من 630 إصداراً خبيثاً في 317 حزمة npm في 20 دقيقة — مستهدفةً TanStack (12 مليون تنزيل أسبوعي) وUiPath وتكاملات MistralAI عبر استغلال مسارات CI/CD. حمل البرنامج الخبيث (mini Shai-hulud) توقيعات تشفيرية صالحة، تجاوز المصادقة الثنائية، وسرّب البيانات عبر Session، تطبيق مراسلة مجهول.

الخلاصة: يجب على فرق الهندسة مراجعة أذونات GitHub Actions في جميع المستودعات فوراً، والتحوّل إلى التبعيات المثبّتة بهاش للحزم الحرجة، وتكوين تصفية الاتصالات الصادرة لبيئات البناء لحظر اتصالات تطبيقات المراسلة — كل ذلك قابل للتنفيذ في السبرينت الحالي دون ميزانية إضافية.

اقرأ التحليل الكامل ↓

🧭 رادار القرار

الأهمية بالنسبة للجزائر
عالي
▾
كل فريق تطوير جزائري يستخدم npm أو حزم Python أو تبعيات المصادر المفتوحة في مسارات البناء يواجه نفس التعرض؛ Banxy وSofizPay وفرق تكنولوجيا المعلومات المؤسسية التي تبني على JavaScript/Node.js داخلة مباشرةً في نطاق الهجوم.
البنية التحتية جاهزة؟
نعم
▾
الضوابط الدفاعية (مراجعة صلاحيات GitHub Actions، تثبيت التبعيات، تصفية الحركة الصادرة) تعمل على نفس البنية التحتية التي تستخدمها الفرق بالفعل.
المهارات متوفرة؟
جزئي
▾
إعداد GitHub Actions وأمن CI/CD ضمن قدرات فرق DevOps المؤسسية الجزائرية؛ تطبيق إثبات SLSA يستلزم معرفة أكثر تخصصاً.
الجدول الزمني للعمل
فوري
▾
مراجعة صلاحيات GitHub Actions وتثبيت التبعيات مهام السبرينت الحالي؛ يمكن تكوين تصفية الحركة الصادرة لبيئات البناء في أسبوع.
أصحاب المصلحة الرئيسيون
مهندسو DevSecOps، قادة الهندسة، مُشغِّلو المصادر المفتوحة، مهندسو أمن البنية التحتية
نوع القرار
تكتيكي
▾
الضوابط المطلوبة تغييرات في الإعداد وسير العمل قابلة للتنفيذ من فرق الهندسة دون تغيير تنظيمي.

خلاصة سريعة: يجب على فرق الهندسة الجزائرية إنجاز ثلاثة إجراءات في السبرينت الحالي: إجراء مراجعة صلاحيات GitHub Actions في جميع المستودعات (تطبيق كتل permissions: بالحد الأدنى والموافقة اليدوية لطلبات السحب من forks)، والتحوّل إلى التبعيات المثبتة بالهاش للحزم الحرجة، وتكوين تصفية الحركة الصادرة لبيئات البناء لحظر اتصالات تطبيقات المراسلة — الإجراءات الثلاثة قابلة للتنفيذ في السبرينت الحالي دون ميزانية إضافية.

إعلان

أكثر من 630 إصداراً خبيثاً في 20 دقيقة: الجدول الزمني لهجوم Mini Shai-Hulud

في 19 مايو 2026، حدّدت شركتا الأمن السيبراني StepSecurity وSafeDep وأصدرتا تحذيرات بشأن هجوم نشط لسلسلة التوريد ضد حزم npm المفتوحة المصدر. كان الحجم غير مسبوق في سرعته: نشر TeamPCP أكثر من 630 إصداراً خبيثاً عبر 317 حزمة في نحو 20 دقيقة — معدل يُشير إلى أن أدوات آلية كانت تدير مسار نشر الحزم من جانب المهاجمين.

TeamPCP مجموعة إجرامية إلكترونية تركّز على السحابة، ظهرت في أواخر 2025، متخصصة في أتمتة هجمات سلسلة التوريد واستغلال البنية التحتية الأصيلة للسحابة. تتميز منهجية المجموعة في حملة mini Shai-hulud بعدة عوامل:

  • التحديثات الخبيثة حملت توقيعات تشفيرية صالحة — مما يُثبت أن المهاجمين اخترقوا مسارات CI/CD ذاتها، لا مجرد حسابات المطورين
  • تجاوز البرنامج الخبيث المصادقة الثنائية عبر اختراق مسار CI/CD
  • استغل الهجوم صلاحيات واسعة بشكل مفرط في GitHub Actions، باستخدام التثبيتات المعلّقة (commits مدفوعة إلى forks من المستودعات بدون فروع مقابلة) لحقن التبعية الخبيثة
  • الحمولة — وحدة مبهمة بحجم 2.3 ميغابايت مُخفية كتبعية تهيئة — تُجلب كتبعية مخفية لا كتعديل مباشر للحزمة

حزمة React Router من TanStack وحدها تتلقى أكثر من 12 مليون تنزيل أسبوعي. جُرِّحت أجهزة موظفين في OpenAI عبر مكتبة TanStack في موجة سابقة من نفس الحملة، مما يُثبت أن نصف قطر الانفجار لاختراق حزمة ذات معدل تنزيل عالٍ يمتد بكثير إلى ما وراء مستخدميها المباشرين.

إعلان

كيف يعمل Mini Shai-Hulud: سلسلة الهجوم الكاملة

المرحلة 1 — اختراق مسار CI/CD. حصل TeamPCP على وصول لمسارات CI/CD للحزم المستهدفة باستغلال صلاحيات GitHub Actions الواسعة بشكل مفرط. بدفع التثبيتات المعلّقة، كان TeamPCP يستطيع تشغيل إجراءات CI/CD دون ظهور التثبيت في تدفق مراجعة طلبات السحب القياسي.

المرحلة 2 — نشر مُوقَّع خبيث. لأن الهجوم جرى داخل مسار CI/CD، كان الإصدار الخبيث موقَّعاً بمفتاح التوقيع التشفيري الشرعي للحزمة. هذا هو التمييز الحاسم عن هجمات سلسلة التوريد النمطية: لا تُوفر التحقق من التوقيعات — الدفاع القياسي الموصى به — أي حماية حين تُخترق بنية التوقيع ذاتها.

المرحلة 3 — توصيل عبر تبعية مخفية. لم يصل البرنامج الخبيث كتعديل مرئي على الكود العام للحزمة، بل كتبعية مخفية تجلب حمولة مبهمة بحجم 2.3 ميغابايت مُقنَّعة كوحدة تهيئة. لن يكشف مراجعة كود معيارية لفارق الحزمة المحتوى الخبيث.

المرحلة 4 — تسريب بيانات الاعتماد. عند التنفيذ، يستخدم البرنامج الخبيث Bun (بيئة تشغيل JavaScript) لاستخراج: بيانات اعتماد AWS ورموز وصول Google Cloud Platform وملفات تكوين Kubernetes ورموز HashiCorp Vault ومفاتيح SSH المحلية. يُلاحظ تحليل CyberScoop أن البيانات المسروقة سُرِّبت عبر Session، تطبيق مراسلة مجهول — مُخفيةً سرقة البيانات كحركة دردشة مشفرة.

المرحلة 5 — الثبات عبر تكامل بيئة التطوير. ثبّت البرنامج الخبيث نفسه في ملفات إعداد VS Code وClaude Code، ضامناً التنفيذ التلقائي حين يفتح المطورون مشاريع تحتوي على الحزمة المخترقة.

تابعوا AlgeriaTech على LinkedIn للتحليلات التقنية المهنية تابعوا على LinkedIn
تابعونا @AlgeriaTechNews على X للحصول على أحدث تحليلات التكنولوجيا تابعنا على X

إعلان

الأسئلة الشائعة

كيف تجاوز TeamPCP المصادقة الثنائية على حسابات المطورين؟

لم يهاجم TeamPCP حسابات المطورين مباشرةً — بل اخترق مسار CI/CD ذاته، باستغلال صلاحيات GitHub Actions الواسعة بشكل مفرط تحديداً. بدفع التثبيتات المعلّقة (تغييرات كود على forks بدون مراجع فروع مقابلة)، كان بإمكانهم تشغيل سير عمل CI/CD دون ظهور التثبيت في تدفق مراجعة طلبات السحب القياسي. لأن مسار CI/CD كان يمتلك بيانات اعتماد التوقيع ونشر الحزم، كان الإصدار الخبيث موقَّعاً بالمفتاح الشرعي ومنشوراً عبر المسار الشرعي — متجاوزاً المصادقة الثنائية على مستوى الحساب بالكامل.

ما الذي يجعل mini Shai-hulud أصعب في الكشف من هجمات سلسلة التوريد النمطية؟

ثلاثة عوامل تقنية تجعله غير عادي في صعوبة الكشف بالأدوات القياسية. أولاً، حملت الإصدارات الخبيثة توقيعات تشفيرية صالحة — ما يعني أن أدوات التحقق من التوقيعات تُبلّغ عنها كشرعية. ثانياً، وصلت الحمولة الخبيثة كتبعية مخفية (مجلوبة في وقت التشغيل) لا كود مرئي في فارق الحزمة. ثالثاً، سُرِّبت بيانات الاعتماد المسروقة عبر Session (تطبيق مراسلة مجهول)، مُخفيةً سرقة البيانات كحركة دردشة مشفرة وتتفادى أدوات مراقبة الشبكة.

هل يمنع إثبات SLSA هجمات سلسلة التوريد كـ mini Shai-hulud منعاً كاملاً؟

كان إثبات SLSA على المستوى 2 سيُعقّد هجوم mini Shai-hulud تعقيداً كبيراً بإلزام كل بناء بإنتاج إثبات أصل موقَّع يربط الحزمة المنشورة بـ commit مصدر مراجَع محدد وعملية بناء مصادق عليها. كان بناء مُشغَّل بتثبيت معلّق سيفشل في إنتاج إثبات صالح مطابق لـ commit مصدر معتمد، مُنبّهاً المستهلكين في المراحل التالية. غير أن SLSA ليس دفاعاً كاملاً: إذا اخترق المهاجم بيئة البناء ذاتها، قد يستطيع إنتاج إثباتات كاذبة. SLSA Level 2 تحسين جوهري؛ SLSA Level 3 (بنيات معزولة ومحكمة) يوفر ضمانات أقوى.

ما يجب على مهندسي الأمن فعله تجاه مخاطر سلسلة توريد المصادر المفتوحة