اتخذت GitHub خطوة بإلغاء صلاحية تكوينات النشر الموثوق غير المُتحقق منها في npm بعد 48 ساعة من إنشائها، بعد أن اكتشف باحثون أنه كان بإمكان مهاجم نشر إصدارات جديدة من حزمة مستخدم آخر دون الحاجة إلى سرقة بيانات اعتماده.
وقالت الشركة التابعة لمايكروسوفت: “يصبح تكوينك مُتحققاً منه ومُعفى من انتهاء الصلاحية بعد أول عملية نشر ناجحة. تغيير هوية المستودع أو المشروع يتطلب علاقة ثقة جديدة مع نافذة تحقق جديدة مدتها 48 ساعة، والتعديلات العادية لا تعيد تشغيل المهلة”. وأضافت GitHub أن هذا التغيير يحتوي المخاطر المرتبطة بالثقة في اسم مستودع أو مشروع يتغير مالكه، مشيرة إلى أن npm ترفض أيضاً من الآن فصاعداً رموز النشر الموثوق الصادرة من أحداث issue_comment في GitHub Actions، إلى جانب قيد pull_request_target القائم بالفعل.
وفي تحديث لوثائقها، ذكرت GitHub أن تكوين الناشر الموثوق المنشأ حديثاً يجب أن يكمل أول عملية نشر ناجحة خلال يومين، وهو ما يتحقق من التكوين ويربطه “بالهوية غير القابلة للتغيير للمستودع”.
كيف اكتُشفت الثغرة؟
يأتي هذا التطور استجابة لنتائج شركة Bloom Security التي اكتشفت ثغرة في نظام النشر الموثوق في npm تتيح الاستيلاء على آلاف الحزم وإطلاق هجوم سلسلة توريد متتالٍ على غرار Shai-Hulud. وقد أُبلغ GitHub بالنتائج في 6 يونيو 2026. وقال الباحث الأمني غولان مايرز: “تخيل هذا: مهاجم يخترق حزمة واحدة. وكيل ذكاء اصطناعي على جهاز مشرف حزمة شهيرة يسحبها تلقائياً لمشروع ما. تُستخدم نقطة النهاية الواحدة هذه لدفع شيفرة خبيثة إلى الحزمة الشهيرة. فيتعرض جميع مستخدمي الحزمة للخطر، كل ذلك لأن شخصاً واحداً يملك الوصول الصحيح تعرض للاختراق”.
##### ما هو النشر الموثوق وكيف يعمل
أُدخل النشر الموثوق في npm في يوليو 2025 كطريقة مصادقة بلا بيانات اعتماد تتيح للمطورين دفع حزم npm من منصة CI/CD مثل GitHub Actions باستخدام رموز OpenID Connect. وعند تكوين النشر الموثوق، يولّد مزود CI/CD للمطور رمزاً تشفيرياً قصير الأجل لتشغيل سير عمل محدد تتحقق منه سجلات npm مقابل تكوين مُصرح به مسبقاً. ويلغي هذا الحاجة إلى تخزين أسرار npm طويلة الأجل أو تدويرها أو إدارتها يدوياً، مما يقلل خطر تسرب بيانات الاعتماد. كما يولّد تلقائياً إثباتات المصدر لحزم npm، مما يتيح للمستخدمين تحديد مكان بناء الحزمة ومن نشرها، وبذلك يعزز أمن سلسلة التوريد البرمجية.
جوهر الخلل في تحديد هوية المستودع؟
غير أن Bloom Security وجدت أن هذه البنية الأمنية تعاني من مشكلة في طريقة تعريفها للمستودع، والمعروف أيضاً بالاسم المختصر، وهو مزيج المالك أو المنظمة واسم المستودع بصيغة “owner/repository”. وشرح مايرز: “تسجّل عنوان المستودع بدلاً من المعرّف الدائم الذي تمنحه GitHub له، على الأقل حتى يُنشر إصدار أول من ذلك المستودع. إنه كقفل يتحقق من العنوان على الباب لا من مالك المنزل: فعندما ينتقل المالك، يحصل من ينتقل إليه على المفتاح”.
وبعبارة أخرى، فإن المعرّفات الرقمية التي تبقى عبر إعادة تسمية المستودعات ونقلها تحملها رموز OIDC الخاصة بـ GitHub، لكن npm تتجاهلها تماماً حتى أول عملية نشر ناجحة من ذلك المستودع. وهذا يعني أن الثقة مرتبطة باسم لا بمعرّف مستودع غير قابل للتغيير، وهي ثغرة يمكن استغلالها بالمطالبة بأسماء مختصرة متروكة لوراثة ثقتها.
شروط الهجوم وخطواته
لكي ينجح هذا الهجوم، الشرط الوحيد هو أن يشير ناشر الضحية الموثوق إلى اسم GitHub مختصر يمكن للمهاجم المطالبة به، وأن المستودع لم يُستخدم قط لنشر إصدار من الحزمة على npm. وبمجرد أن يصبح هذا الاسم متاحاً بعد إعادة تسمية المشرف للمستودع أو نقله أو حذفه، يمكن للمهاجم اتباع الخطوات التالية: إنشاء مستودع في الاسم المحرر على المسار “owner/repository” مما يدفع GitHub لإصدار معرّف مستودع جديد. وإنشاء سير عمل نشر npm وتشغيله، مما يسكّ رمز OIDC يحمل الاسم المستعاد والمعرّف الرقمي الجديد للمستودع. ثم تقديم الرمز إلى نقطة تبادل npm، فتجد npm أن claim المستودع يطابق الاسم المخزن وتصدر بيانات اعتماد نشر. وبذلك يحصل المهاجم على رمز نشر محدود المدة لحزمة لا يملكها ويدفع تغييرات خبيثة إلى السجل.
وهجوم من هذا النوع، يحمل الاسم الرمزي SlugFest، يمكن استغلاله لنشر إصدار “خبيث” جديد من حزمة الضحية تحت اسم الحزمة الشرعي، مع وراثة السمعة الحالية وعدد التنزيلات والعلاقات التابعة. وهذا بدوره يمكن أن يؤدي إلى هجمات سلسلة توريد واسعة النطاق.
تضاعف المخاطر مع وكلاء الذكاء الاصطناعي
يمكن لوكلاء الذكاء الاصطناعي العاملين على أجهزة المطورين أن يضاعفوا الخطر. وقالت Bloom Security: “الوكلاء يحلون التبعيات بأنفسهم، ويميلون إلى أخذ أحدث إصدار، ونادراً ما يتحققون من مصدر الحزمة. فالإصدار الخبيث المنشور عبر اسم مستعاد يُسحب ويُشغَّل دون أي تدخل بشري”. وقالت الشركة إنها وجدت أكثر من 1500 حزمة معرضة للخطر جرى تنزيلها مجتمعة أكثر من 10 ملايين مرة.
ما ينبغي للمطورين فعله
يُنصح المطورون الذين يحتفظون بحزم npm باتخاذ الإجراءات التالية: تدقيق ارتباطات الناشر الموثوق والتحقق مما إذا كان اسم المستودع المدرج لا يزال يشير إلى المستودع الخاضع لسيطرتهم. وإذا أُعيدت تسمية المستودع أو نُقل، حذف ارتباط الثقة القائم وإعادة إنشائه موجهاً إلى الاسم الحالي. ومراقبة أحداث النشر غير المتوقعة في npm. وحذف ارتباطات الثقة كلما حُذف مستودع أو نُقل أو أُعيدت تسميته.
وقال مايرز: “الهجوم لا يتطلب معرفة داخلية ولا سرقة بيانات اعتماد ولا حالة سباق. الشرط المسبق الوحيد هو توفر الاسم المختصر على ارتباط لم يُستخدم بعد للنشر، وهو أمر يتوقف بالكامل على نظافة المستودع لدى الضحية نفسها”. وأضاف: “ما يوضحه هذا البحث هو شيء رآه مجتمع الأمن مراراً في هجمات سلسلة التوريد: الارتباط بين معرّف مقروء بشرياً والشيء الذي يعرّفه هو الثابت الأهم في أي نظام ثقة. وعندما يمكن استبدال هذا الارتباط بصمت، بالفعل العادي لإعادة تسمية مستودع لا بفعل مهاجم، تنهار ضمانات الثقة”.
أسلوب هجوم آخر مرتبط
ليست هذه المرة الأولى التي تُكتشف فيها ناقلات هجوم غير تقليدية على سلسلة التوريد. ففي أغسطس الماضي، وجدت Bloom Security أيضاً أن كلاً من Open VSX وسوق إضافات VS Code من مايكروسوفت يسمحان لحزم الإضافات بالإشارة إلى إضافات غير موجودة في الأسواق. وتقنية “إحياء الإضافات” هذه يمكن تسليحها لاختطاف إضافات مشار إليها بالفعل داخل هذه الحزم الموثوقة بمجرد المطالبة بنطاق تُرك بلا مطالبة. وقد صُنفت ما يصل إلى 87 حزمة في Open VSX و677 حزمة في سوق VS Code على أنها معرضة للخطر. وأشار مايرز حينها إلى أن “المهاجمين يمكنهم المطالبة بتلك الفتحات الفارغة ونشر شيفرة خبيثة تحتها وتثبيتها تلقائياً إلى جانب الحزمة الموثوقة، ودفع تحديثات بصمت إلى كل من ثبّت الحزمة سابقاً. ولأن الإضافات تعمل بوصول كامل إلى المضيف، فإن هذا يرقى فعلياً إلى تنفيذ تعليمات برمجية عن بُعد تحت غطاء الشرعية”.
