تأثير مرتفعالأمنلا يوجد تصحيح بعد

برمجية خبيثة على npm باسم oktz-baileys تجعل حسابات WhatsApp تتابع قناة مضمّنة في الشيفرة

نسخة متفرعة خبيثة من Baileys على npm تستخدم جلسة WhatsApp المرتبطة الخاصة بمن يثبّتها لمتابعة قناة اختارها مؤلف الحزمة. العلاج الوحيد هو إزالتها، إذ لا يوجد إصدار مُصحِّح.

مكتب خالد أبوبكر الهندسينُشر

تحليل هندسي آلي من مكتب خالد أبوبكر الهندسي، مبني على المصادر الأولية المذكورة أدناه. لم يراجعه شخص قبل النشر. عن المكتب

الخلاصة

تُصنَّف oktz-baileys برمجيةً خبيثة، ولا يوجد إصدار مُصحِّح، فجميع الإصدارات مدرجة على أنها متأثرة. غير أن السلوك الذي جرى تحليله أضيق مما يوحي به تصنيف "حرج": فهي تستخدم جلسة WhatsApp المرتبطة لديك لمتابعة قناة مضمّنة في الشيفرة، ولا تصف الأدلة أي سرقة لبيانات الاعتماد. أزِلها من كل مشروع، وتحقّق من أن حساب WhatsApp المرتبط لا يتابع قناة غير مرغوب فيها، وانتقل إلى مصدر لـ Baileys راجعته.

ماذا حدث

نشرت GitHub النشرة الأمنية GHSA-wmf5-rghr-gxcf بتاريخ 2026-11-06، وهي تصنّف حزمة npm المسمّاة oktz-baileys برمجيةً خبيثة. والحزمة نسخة متفرعة (fork) من مكتبة Baileys الخاصة بـ WhatsApp Web. ووفقًا للنشرة، تجعل الحزمة حساب WhatsApp الموثّق الخاص بمن يثبّتها يتابع خِفيةً قناة WhatsApp (WhatsApp Channel) اختارها مؤلف الحزمة.

جاء هذا الاكتشاف من مراجعة ساكنة لأرشيف الحزمة المنشور (tarball) للإصدار 9.1.6 بتاريخ 2026-10-16، ولم يُشغَّل الأرشيف. وعثرت المراجعة على معرّف JID لقناة مضمّن في الشيفرة هو 120363400911374213@newsletter، كما عثرت على طلب متابعة قناة مُعَدّ لينطلق تلقائيًا فور اتصال المقبس (socket). وتُكتَم الأخطاء الناتجة عن هذا الطلب، فلا يظهر للمطوّر أي شيء.

ينسب سجل OpenSSF، MAL-2026-18712، الحزمة إلى الحملة التي وثّقتها OX Security باسم "PhantomSub". ويصفها السجل أيضًا بأنها من العائلة نفسها التي ينتمي إليها MAL-2026-4519، وهو سجل يخص chromestaff-baileys 1.1.3 سُحب لاحقًا. ولا تذكر الأدلة سبب سحبه.

حتى 2026-10-16 كانت الحزمة لا تزال متاحة على npm ولم يكن لها سجل في OSV. وتصنّف النشرة المهيكلة جميع الإصدارات الأعلى من 0 على أنها متأثرة، ولا تذكر أي إصدار مُصحِّح. وتمنح السجل تصنيف "حرج" مع درجة CVSS قدرها 0.

لماذا يهم

تعمل Baileys بجلسة WhatsApp حيّة وموثّقة، ولذلك ترث أي نسخة متفرعة منها كل ما يُسمح لتلك الجلسة بفعله. والحمولة المُبلَّغ عنها هنا صغيرة: استدعاء متابعة واحد لقناة ثابتة. غير أن النقطة الأهم هي أن المكتبة تمتلك الجلسة أصلًا، فلا تحتاج إلى استغلال ثغرة أمنية أو تصعيد الصلاحيات أو سكربت تثبيت كي تتصرف باسم الحساب.

الفرق المتأثرة هي تلك التي تبني على Baileys بوتات WhatsApp أو تكاملات لمراسلة العملاء أو خدمات إشعارات. فإن اختار أحدها هذه النسخة المتفرعة، فقد يكون رقم العمل المرتبط بتلك الخدمة يتابع الآن قناة لم يخترها أحد. وبالنسبة إلى المؤسسات في القطاعات الخاضعة للتنظيم، كالرعاية الصحية أو المراسلات الحكومية، فإن أي إجراء غير مصرَّح به على الحساب يُعدّ مسألة حوكمة في حد ذاته، بصرف النظر عن الضرر المباشر.

ويبالغ تصنيف "حرج" في تقدير ما رُصد فعليًا. فالأدلة لا تصف أي سرقة لبيانات الاعتماد ولا تسريب للبيانات ولا أي سلوك يتجاوز استدعاء المتابعة، لكنها كذلك لا تستبعد ذلك.

التقييم الهندسي

تقييمنا: هذا اختراق حقيقي لسلسلة التوريد بأثر مرصود محدود، والتصنيف يضخّم ذلك الأثر. تعامل معه بوصفه أولوية عالية، لا حالة طوارئ.

السلوك المرصود إساءة استخدام للحساب، لا اختراق للنظام. فاستدعاء متابعة مضمّن في الشيفرة يُنفَّذ عند الاتصال ويُخفي أخطاءه مصمَّمٌ لتنمية جمهور قناة بهدوء. ولا شيء في الأدلة يشير إلى أنه يقرأ متغيرات البيئة أو يتعامل مع نظام الملفات أو يرسل مواد الجلسة إلى أي مكان. وبحسب الأدلة المتاحة، لم يثبت أن الأجهزة المضيفة التي تشغّل هذه الحزمة مخترقة؛ فما أُسيء استخدامه هو هوية WhatsApp المرتبطة.

ثمة تحفّظان يحدّان من هذا الاستنتاج. أولًا، كانت المراجعة ساكنة واقتصرت على الإصدار 9.1.6؛ فالإصدارات الأخرى مُعلَّمة لكنها غير موصوفة، ولم يُرصد السلوك أثناء التشغيل. ثانيًا، الشيفرة القادرة على إرسال طلب متابعة عبر جلسة موثّقة قادرة، من حيث المبدأ، على إرسال طلبات أخرى أيضًا. فمشكلة الثقة ليست في استدعاء المتابعة بحد ذاته، بل في أن نسخة متفرعة مجهولة المصدر كانت تملك صلاحية الاستخدام الكامل للجلسة.

والدرس البنيوي واضح. ثمة نسختان متفرعتان على الأقل تحملان اسم Baileys يربط بينهما هذا السجل: oktz-baileys المنسوبة إلى PhantomSub، وchromestaff-baileys الموصوفة بأنها من العائلة نفسها في سجل سُحب لاحقًا. ثبّت Baileys على مصدر راجعت ناشره وشيفرته، وتعامل مع أي مكتبة تمتلك جلسة مراسلة بوصفها شيفرة ذات امتيازات تستلزم المراجعة قبل إضافتها أو استبدالها.

وتترك النشرة مسألة التنظيف مفتوحة. فإلغاء تثبيت الحزمة يوقف استدعاءات المتابعة المستقبلية، لكن لا شيء في الأدلة يشير إلى أنه يُلغي متابعة حدثت بالفعل. وهذا أمر يجب التحقق منه على حساب WhatsApp نفسه.

هل يعنيك هذا؟

  • مشروعك على Node.js، أو أي اعتمادية فيه، يجلب oktz-baileys بأي إصدار عند حلّ الاعتماديات.
  • تشغّل بوت WhatsApp أو تكامل مراسلة مبنيًا على نسخة متفرعة من Baileys بدلًا من مصدر تحققت منه.
  • حساب WhatsApp مرتبط بإحدى خدماتك يتابع قناة لم يخترها أحد في فريقك.
  • على سبيل الاحتياط فقط: يحتوي ملف القفل (lockfile) لديك على chromestaff-baileys (ذكر السجل المسحوب الإصدار 1.1.3). لا يُعدّ برمجية خبيثة مؤكدة بحسب الأدلة الحالية، لكنه يستحق المراجعة.

للتحقق من مشروع:

npm ls oktz-baileys chromestaff-baileys
grep -E "oktz-baileys|chromestaff-baileys" package-lock.json yarn.lock pnpm-lock.yaml
grep -rl "120363400911374213" node_modules

ما الذي ينبغي فعله

  1. أزِلها الآن. لا يوجد إصدار مُصحِّح، فالترقية ليست خيارًا. ألغِ تثبيت oktz-baileys من كل مشروع وكل صورة حاوية، ثم أعد البناء انطلاقًا من ملف قفل نظيف.
  2. استبدلها بمصدر خضع للمراجعة. انتقل إلى مصدر لـ Baileys تحققت من ناشره وشيفرته، واختبر الاتصال وإعادة الاتصال وتدفقات الرسائل قبل النشر.
  3. افحص الحساب المرتبط. على كل حساب WhatsApp شغّل الحزمة، ابحث عن قناة متابَعة لم يخترها أحد وألغِ متابعتها يدويًا. هذا ليس توجيهًا من المورّد؛ إذ لم تُنشر خطوات معالجة رسمية.
  4. فكّر في إعادة ربط الجلسة. على سبيل الاحتياط، سجّل خروج الجهاز المرتبط ثم أعد إقرانه باستخدام البناء النظيف. هذا ليس توجيهًا من المورّد؛ فالمراجعة غطّت إصدارًا واحدًا بصورة ساكنة ولا يمكنها استبعاد سلوك آخر.
  5. احظرها في خط التكامل المستمر. أضف oktz-baileys إلى قائمة حظر الاعتماديات أو إلى بوابة تدقيق. أما chromestaff-baileys، الذي سُحب سجله لأسباب لا تذكرها الأدلة، فإن إدراجه في قائمة الحظر أو مراجعته يدويًا إجراء احتياطي حذر. هذا ليس توجيهًا من المورّد بالنسبة إلى chromestaff-baileys.
  6. للقادة التقنيين: أعدّوا قائمة بكل خدمة تمتلك جلسة مراسلة موثّقة، ودوّنوا مصدر مكتبة العميل الخاصة بها، واشترطوا المراجعة قبل إدخال أي نسخة متفرعة جديدة. وعلى الفرق التي تدمج المراسلة في منصات الويب أن تتعامل مع هذه المكتبات بوصفها شيفرة ذات امتيازات. هذا ليس توجيهًا من المورّد.

ما لا نعرفه بعد

  • ما إذا كان لا يزال بالإمكان تنزيل الحزمة من npm اليوم؛ فالأدلة تؤكد فقط أنها كانت متاحة في 2026-10-16.
  • عدد عمليات تثبيتها أو الحزم المعتمدة عليها.
  • ما إذا كانت الإصدارات الأخرى غير 9.1.6 تتصرف بالطريقة نفسها، أو ما إذا كان أي إصدار يفعل أكثر من متابعة القناة.
  • كيفية اكتشاف الاشتراك وإلغائه، بخلاف فحص الحساب يدويًا.
  • سبب سحب السجل MAL-2026-4519 الخاص بـ chromestaff-baileys.
  • سبب ظهور نشرة GitHub في 2026-11-06، بعد ثلاثة أسابيع من تحليل OpenSSF، وما إذا كانت الحزمة قد أُزيلت في الفترة الفاصلة.
  • ما إذا كانت نسخ متفرعة أخرى من Baileys تنتمي إلى حملة PhantomSub.

سيتابع فريق التحرير صفحة الحزمة على npm وسجل OpenSSF، وسيحدّث هذا المقال إذا أُجيب عن أيٍّ من هذه الأسئلة.

المصادر

أحدث التحليلات الهندسية

قراءة 2 دقيقة

مثال في دليل إعداد AWS REX خلّف وثائق SSM قابلة لحقن الأوامر

ثغرة أمنية من نوع حقن الأوامر في السكربت المثال من دليل إعداد Trusted Remote Execution من AWS تتيح لمن يستدعي مستندات SSM تشغيل أوامر نظام التشغيل خارج بيئة Cedar المعزولة، ولن يكتشفها لك أي تصحيح أو أداة فحص.

قراءة 2 دقيقة

solidity-map على npm: حمولة البرمجية الخبيثة نفسها تحت اسم حزمة ثالث

تصنّف قاعدة بيانات النشرات الأمنية في GitHub الحزمة solidity-map 2.21.0 برمجيةً خبيثة تعيد استخدام حمولة hardhat-roof وchai-foundry بايتًا ببايت. لذلك ستظل قوائم الحظر القائمة على الأسماء عاجزة عن رصد الاسم الجديد التالي.

قراءة 2 دقيقة

loader-utils-kit: أداة الإسقاط الخبيثة pino-testkit على npm تعود باسم جديد

أُعيد نشر أداة الإسقاط المموّهة lib/contract.js، التي ظهرت أولًا في pino-testkit، تحت اسم loader-utils-kit. لذلك لا تلتقطها قوائم الحظر القائمة على الأسماء، وينبغي للفرق البحث ببصمة الملف (hash) إلى جانب الاسم.