حزمة bee-js الخبيثة نُشرت على npm عبر workflow المشروع الرسمي بتوقيعات provenance سليمة
في 9 نوفمبر 2026 نُشر الإصدار 13.3.0 من حزمة @ethersphere/bee-js على npm في الساعة 00:09:50 بتوقيت UTC، وأُزيل في 01:24:58، أي بعد نحو 75 دقيقة. وصدر الـ advisory الخاص به في 01:25:27. وخلال تلك المدة كانت الحزمة تحمل كودًا خبيثًا، بينما كانت توقيعات الـ provenance الخاصة بها سليمة.
بحسب تحليل Socket، وصل المهاجم إلى حسابين على GitHub: حساب nugaon، وهو أحد الـ maintainers ويملك صلاحية force-push على فرع master غير المحمي، وحساب bee-worker، وهو حساب الروبوت الذي يتولى نشر الإصدارات. ويقول التحليل إن أصل الاختراق أقدم من 6 نوفمبر، ولم يُفسَّر بعد.
اللافت أن المهاجم لم ينشر الحزمة بنفسه. أنشأ release جديدًا على GitHub، فشغّل ذلك workflow النشر الرسمي للمشروع، وهو الذي نشر الحزمة على npm. وتنص عبارة التحليل حرفيًا على أنه لم تكن هناك حاجة إلى npm token.
وقع التعديل في commit غير موقّع منسوب إلى حساب الروبوت، داخل ملف صغير مهمته توليد رقم الإصدار، فصار يجلب كودًا من خادم خارجي ويشغّله. وفي package.json تغيّر hook من prepare إلى postinstall. والفرق جوهري: الأول يعمل عند تجهيز الحزمة للنشر، والثاني يعمل على جهاز كل من يثبّتها. ويقول التحليل إنها المرة الأولى في تاريخ الحزمة التي تحتوي فيها على hook يعمل وقت التثبيت.
لماذا لم يكشف الـ provenance شيئًا
الـ provenance شهادة تربط الحزمة المنشورة بالمستودع والـ workflow اللذين بُنيت منهما. وقد تحقق منها الباحثون offline ووجدوها غير مزورة، لأن الحزمة بُنيت فعلًا من مستودع المشروع. ويلخص التحليل ذلك بأن الـ provenance يثبت أين بُنيت الحزمة، لا أن أحدًا راجع الكود الذي بُني.
وتكرر النمط في تطبيق Swarm Desktop بإصداره 0.56.2. كان الـ workflow الذي جرى تشغيله يملك وصولًا إلى شهادات توقيع Apple وWindows، فجرى البناء والتوقيع بين 00:41:24 و00:44:55 بتوقيت UTC، وحصلت النسخة على notarization من Apple، ووصلت إلى المستخدمين عبر التحديث التلقائي بين 00:43 و00:44.
بالنسبة إلى الفرق في المنطقة التي تنشر حزمها أو تطبيقاتها من CI، يغيّر هذا الحادث تعريف الصلاحية الحساسة. لم تعد في الـ token وحده، بل في كل حساب أو حدث يستطيع تشغيل workflow النشر، وفي كل سر يصل إليه ذلك الـ workflow، بما فيه شهادات التوقيع. والإجراء الذي يقترحه التحليل بسيط: أن يتحقق الـ workflow من أن الـ commit موجود على فرع محمي قبل النشر.
والإصدارات السليمة بحسب التحليل هي bee-js 13.2.0 أو أقدم، وSwarm Desktop 0.56.1. ويمكن البحث في سجلات DNS والـ proxy عن النطاق api.frameworkmetrics.xyz لمعرفة ما إذا كان أي جهاز قد اتصل بالخادم الخبيث.