حزمة npm خبيثة ظهرت بعد اختراق مستودع جيت هاب لمشروع تابع لـ إنجكتيف لابس، ما عرّض مفاتيح المحافظ وعبارات الاسترداد لخطر التسريب.
ما قصة حزمة npm خبيثة المرتبطة بـ إنجكتيف لابس؟
الهجوم بدأ بعد اختراق مستودع GitHub الخاص بحزمة تطوير برمجيات تابعة لـ Injective Labs، ثم استُخدم هذا الوصول لنشر إصدار ملوث على سجل npm. الإصدار المتأثر حمل الرقم 1.20.21 من الحزمة @injectivelabs/sdk-ts.
الخطورة هنا لا تتعلق بملف عادي أو تحديث محدود، بل بحزمة برمجية تُستخدم داخل تطبيقات مرتبطة بالمحافظ الرقمية. وهذا يعني أن أي مطور سحب النسخة المصابة قد ينقل الخطر إلى المستخدمين النهائيين دون أن يلاحظ بسرعة.
- الإصدار المصاب: 1.20.21
- تاريخ النشر: 8 يوليو 2026
- الهدف: سرقة المفاتيح الخاصة وعبارات الاسترداد
- حالة الإصدار: تم إيقافه على npm لكن بعض الملفات ما زالت متاحة للتنزيل
كيف نجحت البرمجية الخبيثة في سرقة مفاتيح المحافظ؟
بحسب التفاصيل المتاحة، لم تعتمد البرمجية الخبيثة على أسلوب صاخب مثل أوامر التثبيت التلقائية أو سكربتات lifecycle التي ترصدها أدوات الحماية بسرعة. بدلاً من ذلك، انتظرت حتى يبدأ المطور باستخدام وظائف المكتبة بشكل طبيعي.
تمويه على هيئة قياس أداء
الشفرة الملوثة أضافت وظيفة تبدو وكأنها مخصصة لجمع بيانات استخدام مجهولة لتحسين الأداء. لكن عملياً، كانت تستقبل معلومات حساسة مرتبطة بطرق توليد المفاتيح، بما في ذلك بيانات كافية لإعادة إنشاء المفتاح الخاص لدى المهاجم.
- تسجيل طريقة اشتقاق المفتاح
- التقاط عبارات mnemonic أو بيانات مرتبطة بها
- إرسال المعلومات إلى جهة خارجية بصمت
- العمل أثناء الاستخدام الفعلي لا أثناء التثبيت
هذه النقطة تجعل حزمة npm خبيثة أكثر خداعاً، لأنها تتخفى داخل وظيفة تبدو تقنية ومنطقية في سياق تطوير المحافظ الرقمية.
ما مدى اتساع الهجوم على حزم npm الأخرى؟
المشكلة لم تتوقف عند حزمة واحدة فقط. إذ امتد الإصدار 1.20.21 إلى 17 حزمة إضافية ضمن نطاق @injectivelabs، وكانت هذه الحزم تعتمد مباشرة على النسخة المصابة وتثبتها بشكل صريح.
هذا السيناريو يوسّع دائرة الخطر إلى ما يسمى بالمستخدمين غير المباشرين أو transitive users، أي مطورين لم يثبتوا الحزمة الأصلية بأنفسهم لكنهم حصلوا عليها عبر تبعيات أخرى. وهنا تظهر هشاشة سلسلة التوريد البرمجية بشكل واضح، وهو ما تتابعه تيكبامين باهتمام في ملفات الأمن الرقمي والعملات المشفرة.
- الضرر قد يصيب مشاريع لا تعرف أنها تستخدم الحزمة الأصلية
- التبعيات المقفلة على إصدار محدد تزيد صعوبة الاكتشاف
- التأثير المحتمل يشمل تطبيقات محافظ وأدوات Web3
ماذا يجب أن يفعل المطورون الآن لتفادي الخطر؟
الخطوة الأولى هي مراجعة التبعيات فوراً والتأكد من عدم وجود الإصدار المصاب داخل المشروع أو أي حزمة مرتبطة به. كما يُنصح بتدوير المفاتيح الخاصة وعبارات الاسترداد إذا كانت قد مرت عبر بيئة تطوير استخدمت هذه المكتبة.
إجراءات عاجلة موصى بها
- فحص ملفات package-lock و yarn.lock
- إزالة الإصدار 1.20.21 من جميع البيئات
- تحديث الحزم إلى إصدارات موثوقة
- تغيير المفاتيح والعبارات السرية المعرضة للخطر
- مراقبة أي اتصالات خارجية غير معتادة من التطبيق
في النهاية، تكشف هذه الحادثة كيف يمكن أن تتحول حزمة npm خبيثة إلى تهديد مباشر للأموال الرقمية، لا سيما عندما تضرب مشروعاً موثوقاً في سلسلة التوريد. ووفق متابعة تيكبامين، فإن سرعة التدقيق في التبعيات أصبحت ضرورة لا خياراً لأي فريق يعمل في مجال الكريبتو.
