حين تنزّل نموذجاً من Hugging Face لتجربته، فأنت تفترض أنك تنزّل أوزاناً رقمية لا برنامجاً. هذا الافتراض هو ما استغلته حملة سمّتها شركة Pluto Security «Load/Mine»، وأعلنت تفاصيلها في 29 أكتوبر 2026. الحملة شملت 31 مستودع نماذج خبيثاً موزعة على سبعة حسابات، وتجاوزت تنزيلاتها 32 ألف مرة بحسب ما نُشر. في هذا المقال نشرح كيف عمل الهجوم، ولماذا لا تعني أرقام التنزيل بالضرورة 32 ألف إصابة، وما الذي يجب أن تفعله الآن إن كنت تجرّب نماذج مفتوحة على جهازك أو خوادمك.

ما الذي حدث بالضبط؟

حملة Load/Mine على Hugging Face: 31 نموذجاً خبيثاً و32 ألف تنزيل، وكيف تحمي جهازك — تريندات تقنية

انتحلت المستودعات صفة نقاط فحص صغيرة (checkpoints) لنموذج Qwen2 للاختبار، وهي أسماء يبحث عنها المطوّرون الذين يريدون نموذجاً خفيفاً للتجربة. لكن هذه المستودعات لم تحمل أوزاناً فقط، بل شيفرة بايثون مخصّصة تعمل عند التحميل. وعندما يفعّل المستخدم الخيار trust_remote_code، تُنفَّذ هذه الشيفرة على جهازه قبل أن يبدأ النموذج بالعمل أصلاً.

وبحسب التقرير، زرعت الشيفرة معدِّن عملة PRL (عملة إثبات عمل)، وآليات بقاء على الجهاز، وفي بعض النسخ أبواباً خلفية للتحكم عن بُعد. وتنكّرت المعدّنات في هيئة عمليات نظام عادية كي لا تلفت الانتباه.

الخط الزمني المختصر

  • 29 أكتوبر 2026: إعلان Pluto Security عن الحملة بعد تتبّع 31 مستودعاً عبر سبعة حسابات.
  • الموجة الثانية: 19 مستودعاً تجاوزت تنزيلاتها 29 ألفاً، وبقيت متاحة ثمانية أيام بعد الإبلاغ عنها.
  • بعد حذف الدفعة الأولى: أنشأ المهاجمون حسابات جديدة وأعادوا رفع المحتوى نفسه.
  • المحافظ الأولى استقبلت نحو 2276 PRL (قرابة 5 آلاف دولار وقت النشر) واستمرت في استقبال المدفوعات بعد الحذف.

لماذا ينجح هذا الهجوم؟

المشكلة ليست ثغرة في Hugging Face بقدر ما هي سلوك مقصود في المكتبات. بعض بنى النماذج الجديدة تحتاج شيفرة مخصصة لا توجد في مكتبة transformers الرسمية، فيسمح الخيار trust_remote_code=True بتنزيلها وتشغيلها. هذا مفيد للباحثين، لكنه عملياً يعادل تشغيل سكربت مجهول المصدر.

تنزيل نموذج مع trust_remote_code ليس تنزيل بيانات، بل تشغيل برنامج كتبه شخص لا تعرفه بصلاحيات حسابك.

ويزيد الأمر سوءاً عاملان: الأول أن الشيفرة تعمل قبل تهيئة النموذج، فلا ترى أي علامة غير طبيعية. والثاني أن الأبواب الخلفية قد تبقى بعد توقف التعدين، فحذف المعدِّن وحده لا يكفي.

هل أُصيب 32 ألف جهاز؟

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

علامات الإصابة المحتملة

ما تفحصه ما الذي تبحث عنه
استهلاك الـGPU والمعالج ارتفاع دائم دون عمل ظاهر، خصوصاً في وقت الخمول
ملفات بدء الصدفة (shell) أسطر جديدة في bashrc أو profile أو zshrc لا تعرفها
المهام المجدولة عناصر غريبة في cron أو مؤقتات systemd
مفاتيح SSH إدخالات مجهولة في authorized_keys
العمليات عمليات بأسماء تشبه خدمات النظام لكن مسارها غير معتاد
ذاكرة التخزين المؤقت للنماذج مستودعات لم تنزّلها بنفسك أو تعرف مصدرها

كيف تحمي نفسك: خطوات عملية

  1. لا تفعّل trust_remote_code افتراضياً. اتركه False، وإن اضطررت فاقرأ ملفات بايثون في المستودع قبل التشغيل.
  2. فضّل صيغة safetensors للأوزان، فهي لا تنفّذ شيفرة عند التحميل بخلاف ملفات pickle القديمة.
  3. تحقق من الناشر. المنظمات الموثّقة وذات التاريخ الطويل أفضل من حساب عمره أيام وعنده اسم قريب من نموذج مشهور.
  4. ثبّت المراجعة (revision) بمعرّف commit محدد بدل الفرع الرئيسي، لئلا يتبدّل المحتوى بعد أن راجعته.
  5. شغّل التجارب في بيئة معزولة: حاوية أو آلة افتراضية بلا مفاتيح ولا بيانات حساسة ولا وصول شبكي غير لازم.
  6. راقب الجهاز: تنبيه عند الاستهلاك غير الطبيعي للـGPU على خوادم التدريب والاستدلال.
  7. إن شككت في إصابة: افحص ملفات البدء والمهام المجدولة ومفاتيح SSH، وأزل المحمّلات والمعدّنات ومراقبي إعادة التشغيل (watchdogs) والأبواب الخلفية، ثم بدّل المفاتيح والأسرار التي كانت على الجهاز.

ماذا يعني هذا لفرق الذكاء الاصطناعي؟

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

كما أن إعادة الرفع بحسابات جديدة بعد الحذف تعني أن الاعتماد على المنصة وحدها في التنظيف غير كافٍ، فالمسؤولية تبقى على من يشغّل الشيفرة.

أسئلة شائعة

هل Hugging Face منصة غير آمنة؟

لا يصح التعميم. المنصة تستضيف ملايين النماذج المشروعة، والمشكلة في قبول شيفرة مجهولة عبر trust_remote_code. الاستخدام الواعي مع التحقق من الناشر يخفض الخطر كثيراً.

هل يكفي حذف النموذج الذي نزّلته؟

لا. إن كانت الشيفرة قد عملت فقد تكون زرعت آليات بقاء وأبواباً خلفية. احذف النموذج، ثم افحص ملفات البدء والمهام المجدولة ومفاتيح SSH، وبدّل الأسرار.

هل ملفات safetensors آمنة تماماً؟

هي أأمن بكثير لأنها لا تنفّذ شيفرة عند التحميل، لكن الخطر يعود إن رافقتها ملفات بايثون مخصصة مع trust_remote_code. الأمان يعتمد على الصيغة وعلى الخيار معاً.

الخلاصة

حملة Load/Mine ليست هجوماً معقداً، بل استغلال لعادة شائعة: تفعيل trust_remote_code لتجربة نموذج جديد دون قراءة ما سيُنفَّذ. الحماية رخيصة: اترك الخيار مغلقاً، وفضّل safetensors، وتحقق من الناشر، وثبّت المراجعة، وجرّب داخل بيئة معزولة. عامل كل نموذج مفتوح كأنه حزمة برمجية من مصدر خارجي، لأنه كذلك.

المصدر: Pluto Security