اختراق Polymarket: 2.7 مليون دولار تُسرق عبر DebugBear المُخترقة

مقدمة تحليلية

في 29 أكتوبر 2026، تعرضت منصة Polymarket لسوق التوقعات لاختراق أمني أدى إلى سرقة ما يقارب 2.7 مليون دولار أمريكي من متداوليها. تم تنفيذ الهجوم عبر حقن شفرة خبيثة في موقع Polymarket، بدلاً من نص برمجي شرعي لقياس سرعة الصفحة يتم تحميله من خدمة DebugBear الخارجية. أظهرت سجلات البلوكتشين أن ما يعادل 2.64 مليون دولار من العملات المشفرة وصلت إلى محفظة القراصنة في أقل من ساعة. أعلنت Polymarket عن إعادة الأموال لحوالي 726 محفظة متأثرة، مما يرفع إجمالي التعويضات إلى 3.9 مليون دولار، بما في ذلك 1.19 مليون دولار للمتداولين الذين تضرروا من توقف التداول أو فقدان مراكزهم.

هذا الحادث يسلط الضوء على هشاشة سلاسل التوريد الرقمية، حيث يمكن أن يؤدي اختراق خدمة خارجية واحدة إلى خسائر مالية جسيمة لمستخدمي المنصات الكبرى.

التحليل التقني

نُفذ الهجوم عبر استغلال سجلات DNS لشركة DebugBear، شريك Polymarket لتقديم أداة مراقبة المستخدم الحقيقية (RUM) التي تقيس سرعة تحميل صفحات الويب. وقد أكدت DebugBear أن سجلات DNS الخاصة بها تعرضت للاختراق من خلال مسجل النطاق الخاص بها، وليس عبر اختراق أنظمتها الداخلية، رغم استمرار التحقيقات. قام القراصنة بتبديل النص البرمجي الشرعي لـ DebugBear بنسخة خبيثة. قام باحثون من Hudson Rock بتنزيل الملف الخبيث في 29 أكتوبر من العنوان الذي استخدمه موقع Polymarket لتحميل نص DebugBear البرمجي، واكتشفوا لاحقاً تغييرًا في شفرة موقع Polymarket أزال النص البرمجي لـ DebugBear.

في 18:13 بالتوقيت العالمي المنسق، وجد باحثون من Ohey أن خادمًا مختلفًا كان يستجيب لعناوين الويب الخاصة بـ DebugBear بينما كان الملف الخبيث لا يزال نشطًا. في وقت سابق من ذلك اليوم، تم تقديم النص البرمجي العادي من Google Cloud Storage.

آلية سرقة الأموال

حلل باحثو Hudson Rock الملف الخبيث، ووجدوا أنه يستغل الوصول الذي يمتلكه المتداولون المسجلون بالفعل في صفحة Polymarket المفتوحة. يقوم النص البرمجي بقراءة تفاصيل الحساب المخزنة في متصفح المستخدم، بما في ذلك مجموعة مفاتيح API للتداول. رغم أن مفاتيح API وحدها لا تكفي لإجراء أوامر على Polymarket لأن الأوامر تتطلب توقيع المحفظة، إلا أن الشفرة تبحث عن الجزء الخاص بإجراء الأوامر على موقع Polymarket، وعن الموقّع الذي يوافق على معاملات الحساب. بعد ذلك، يتخذ الهجوم أحد مسارين:

• للحسابات التي تسجل الدخول بمحفظتها المشفرة الخاصة: يقوم النص البرمجي بتحويل مراكز المتداول مباشرة إلى محفظة القراصنة.
• للحسابات التي تسجل الدخول عبر البريد الإلكتروني: يقوم ببيع المراكز بأسعار تتدهور باستمرار ثم ينقل الأموال.

في كلا المسارين، تطلب الشفرة من موقّع الحساب نفسه توقيع الطلبات وتسليمها إلى مُرحِّل Polymarket الذي يقوم بإرسالها. بدأت المحفظة المبرمجة في تلقي الأموال في 17:10 بالتوقيت العالمي المنسق، وتلقت آخر دفعة في 18:02 بالتوقيت العالمي المنسق. خلال هذه الفترة، جمعت 28.6 مليون رمز POL ومراكز من 33 محفظة. في 18:19 بالتوقيت العالمي المنسق، قُدرت قيمة 28.6 مليون رمز POL بحوالي 2.64 مليون دولار أمريكي، بسعر 0.0922 دولار للرمز الواحد وفقًا لـ DefiLlama، وهو رقم يغطي رموز POL فقط.

تم إرسال جميع الـ 28.6 مليون رمز POL إلى ثلاثة عناوين أخرى بين 18:28 و 18:38 بالتوقيت العالمي المنسق.

السياق وتأثير السوق

تُظهر الاستجابة السريعة من Polymarket وعملية التعويض الشاملة جانبًا من المرونة التشغيلية، إلا أن الحادث نفسه يعكس خطرًا متزايدًا في البنية التحتية للويب الحديثة. في 17:38 بالتوقيت العالمي المنسق، نشرت Polymarket أول تحديث لها حول النشاط غير المصرح به، وبحلول 18:05 بالتوقيت العالمي المنسق، كانت المنصة قد تحولت إلى وضع "إلغاء فقط" مع إيقاف إجراءات المُرحِّل. أكدت الشركة إزالة النص البرمجي "خلال ساعة"، ومسح جميع ذاكرات التخزين المؤقت، وإعادة تعيين جميع جلسات تسجيل الدخول النشطة، وإيقاف التداول حتى تنظيف الموقع. تم إحالة القضية إلى سلطات إنفاذ القانون. بحلول 30 أكتوبر، تم رد كامل المبلغ لـ 689 من 726 محفظة متأثرة، ويتم دفع المبالغ المتبقية لـ 37 محفظة بعد التحقق منها. بالإضافة إلى ذلك، دفعت Polymarket 1.19 مليون دولار أمريكي لحوالي 5,500 محفظة خسرت أموالاً خلال فترة توقف التداول أو تم سحب مراكزها، ليصل إجمالي المبالغ المستردة إلى 3.9 مليون دولار. أشار DebugBear إلى عملائها الذين يستخدمون منتج RUM الخاص بهم بضرورة إزالة شفرة التضمين من مواقعهم، وبحلول 1 نوفمبر، لم يكن لعنوان cdn.debugbear[.]com أي سجل DNS.

في محاولة لتعزيز الأمان المستقبلي، أعلنت Polymarket أنها ستقوم بإعادة دمج النصوص البرمجية للجهات الخارجية مع فحوصات إضافية، مثل سياسة أمان محتوى (CSP) أقوى، وإصدارات مثبتة (pinned versions)، وتطبيقات في بيئة معزولة (sandboxing). يشير هذا إلى تحول محتمل في معايير الأمان للنصوص البرمجية الخارجية، متجاوزًا مجرد السماح لشبكات توصيل المحتوى (CDN) الموثوقة. توصي Hudson Rock المواقع التي تستخدم نصوصًا برمجية خارجية بـ:

• عدم الاحتفاظ بأي كود غير ضروري من طرف ثالث على الصفحات التي يتم فيها تداول المستخدمين أو تسجيل الدخول.
• استخدام Subresource Integrity (SRI) حيث يمكن تثبيت الملفات، مما يسمح للمتصفح برفض الملف إذا تغير محتواه.
• فحص ما يمكن أن يطلبه أي كود على صفحة مسجلة الدخول من الموقّع القيام به.

كما تنصح المتداولين برفض أي طلب توقيع لا يتوقعونه، مما يؤكد الحاجة إلى يقظة المستخدم كطبقة دفاع أخيرة.