استغلال Polymarket: مفتاح مسرَّب لا خلل في العقد
في الثاني والعشرين من مايو 2026، رصد المحقق على السلسلة ZachXBT عملية استنزاف لأحد محافظ Polymarket. وقدّرت التقديرات الأولية الخسارة بنحو 520 ألف دولار. وبحلول الوقت الذي أكّد فيه الفريق التفاصيل، كان الرقم قد اقترب من 660 إلى 700 ألف دولار. لا إعادة دخول، ولا تلاعب بأوراكل، ولا توليف معقد لقروض سريعة. مجرد مفتاح خاص انتهى في مكان لم يكن ينبغي له أن يكون.
لم تمسّ عملية اختراق Polymarket الجزء من التقنيات الذي تدفع الشركات أموالها لـ Trail of Bits وOpenZeppelin لتمحيصه. بل ضربت محفظة تعبئة داخلية، حساباً تشغيلياً يُستخدم لتمويل المكافآت وإبقاء الأمور في مسارها. النوع من المحافظ الذي لا يظهر أبداً في نطاق أي تدقيق لأنه ليس عقداً. إنه مجرد مفتاح يجلس على بنية تحتية لشخص ما.
هذا هو الجانب المقلق. بعد عام كانت فيه العناوين الرئيسية تتحدث عن الجسور وإعدادات DVN الخاطئة، جرى استنزاف سوق التنبؤ الأوفر تمويلاً في العالم من خلال أبسط أوجه الإخفاق في الكتاب.
ما جرى فعلاً على Polygon
كان الحساب المستنزف محفظة عمليات، لا أموال مستخدمين محتجزة في عقود البروتوكول الأساسية. وفقاً لتقرير CoinDesk، رصد ZachXBT نقل ما يقارب من 520 ألف دولار، وأكّد فريق Polymarket أن أموال العملاء بأمان. اجتاح المهاجم POL وأصولاً أخرى من المحفظة على Polygon، ثم فعل ما يفعله المهاجمون دائماً، عبر بها إلى سلاسل أخرى ووزّعها قبل أن يتمكن أحد من تجميدها.
قدّرت Decrypt الرقم بما يقارب 700 ألف دولار وحددت أنها محفظة تعبئة داخلية تحديداً. التفاوت في الأرقام خلال الأربع والعشرين ساعة الأولى أمر طبيعي؛ أما الآلية فليست محل جدل. حصل شخص ما على المفتاح.
هذا استغلال يتعلق بـ Polygon POL فحسب بمعنى أن POL كان الأصل الموجود في المحفظة. السلسلة لم تُخفق. العقد لم يُخفق. ما أخفق هو حفظ أحد المفاتيح التشغيلية.
لماذا لم تكن UMA CTF Adapter هي المشكلة
تعمل آلية تسوية أسواق Polymarket عبر أوراكل UMA التفاؤلي من خلال UMA CTF Adapter، وهو العقد الذي يطرح الأسئلة ويتعامل مع النزاعات ويسوّي النتائج. هذا هو الجزء الذي يحمل، نظرياً، أعلى مستوى من المخاطر العدائية. وقد خضع للتدقيق. وقد اجتاز اختبار الزمن عبر آلاف الأسواق.
ولم يكن له أي علاقة بهذا الأمر.
أعتقد أن هذه هي التفصيلة التي سيتجاهلها الناس ولا ينبغي لهم ذلك. طبقة العقود الذكية صمدت. الأوراكل صمد. ما انهار كان محفظةً يتحكم فيها إنسان بمفتاح يملك الوصول إليه إنسان (أو خط أنابيب CI، أو خدمة توقيع ساخنة). قضينا فترة السوق الصاعد في تصليب الأجزاء التي تخضع للتحقق الرسمي، متجاهلين الأجزاء التي لا تملك سوى ملف .env.
المفاتيح التشغيلية هي سطح الهجوم الحقيقي الآن
هذا هو النمط المتكرر عبر حوادث 2026. كود Solidity يتحسن باستمرار. المدققون يتقنون عملهم. الأساليب الرسمية ترصد أخطاء إعادة الدخول التي كانت تستنزف تسعة أرقام في السابق. فتحرّك المهاجمون.
انتقلوا إلى الأنسجة الرخوة:
- المحافظ الساخنة المستخدمة للمكافآت وتعبئة الغاز وصنع السوق.
- مفاتيح النشر التي لم تُستبدل قط بعد الإطلاق.
- موقّعو المحافظ متعددة التوقيع الذين يستخدمون حاسوباً واحداً للتوقيع والتصفح على حدٍّ سواء.
- أسرار CI/CD القادرة على توقيع المعاملات في بيئة الإنتاج.
لا شيء من هذا يرد في تقرير تدقيق. حين أضع نطاق عمل الأمان في بورصة منظّمة، لا تمثّل مراجعة العقود سوى ثلث العمل. ما تبقى هو وحدات HSM، وفصل الموقّعين، وتوثيق مراسم توليد المفاتيح، والسؤال الممل في عمقه: "من يستطيع تحريك الأموال في الساعة الثالثة صباحاً وما الذي قد يوقفه." هذا الجزء الأخير هو ما تكون فيه معظم الفرق مكشوفة.
هذا هو الدرس ذاته المستخلص من خسارة Kelp DAO في LayerZero، 292 مليون دولار اختفت لا بسبب خطأ في عقد بل بسبب خطأ في الإعدادات على المستوى التشغيلي. آلية مختلفة، سبب جذري واحد: الجزء الممل الذي لا يخضع للتدقيق.
كيف كان يجب أن تبدو المحفظة التشغيلية بقيمة 660 ألف دولار
إذا كان بإمكان مفتاح واحد تحريك 660 ألف دولار، فهذا قرار تصميمي لا حظ سيئ. ثمة أمور عدة ينبغي أن تكون حداً أدنى لأي محفظة تشغيلية تحمل قيمة حقيقية:
- حدود الإنفاق في منطق المحفظة ذاتها. محفظة شحن المكافآت لا مبرر لها أن تكون قادرة على إرسال رصيدها كاملاً في معاملة واحدة. فرض حد للمعدل على السلسلة.
- التوقيع بعتبة لأي مبلغ يتجاوز الحد الأدنى. المدفوعات الآلية الصغيرة يمكن أن تكون ساخنة. أي مبلغ يتجاوز، مثلاً، 10 آلاف دولار يجب أن يستلزم موقعاً ثانياً. التعدد الآمن للتوقيعات مع عتبة منخفضة للتحويلات الكبيرة ليس أمراً عسيراً.
- عزل المفتاح عن بيئة التطبيق. لا ينبغي أبداً أن يكون مفتاح التوقيع لمحفظة العمليات في مكان يمكن لكود التطبيق أو التبعيات أو مشغّل CI المخترق قراءته.
- مراقبة تُنبّه إنساناً عند أي تدفق خارجي شاذ. اكتشف ZachXBT هذا قبل أن يُعلن الفريق عنه. تنبيهاتك الخاصة يجب أن تسبق أي طرف ثالث يراقب الـ mempool.
لا شيء من هذا بجديد. إنه ما يُستغنى عنه حين يكون الفريق مشغولاً بالشحن السريع والمحفظة "مجرد محفظة مكافآت".
الفجوة في منظومة التدقيق التي لا يملكها أحد
المشكلة الأعمق تتعلق بالمسؤوليات، داخلياً. أمن العقود الذكية له مالك واضح: شركة التدقيق. أمن مفاتيح التشغيل له... من قام بإعداد المحفظة، عادةً تحت ضغط المواعيد النهائية، وغالباً لم يُراجَع أبداً. كتبت عن هذه الفجوة في سياق منظومة التدقيق المعطوبة في DeFi، فالشهادة تغطي العقود وتتوقف عند حدودها. كل ما هو تشغيلي خارج النطاق وخارج الاهتمام.
حتى يُلزم مُنظِّم أو مؤمِّن بأن يكون أمن التشغيل بنداً محدداً له مالك، سيستمر هذا في الحدوث. أمن تشغيل DeFi في 2026 يشبه تقريباً وضع أمن العقود الذكية عام 2019: معروف بأهميته، لا يملكه أحد، ويأتي تمويله أخيراً.
ستتجاوز Polymarket هذه الأزمة. 660 ألف دولار خسارة يمكن تحمّلها لمنصة بهذا الحجم، ويُحسب لهم أنهم تواصلوا بسرعة وشفافية. لكن الفريق التالي الذي يتعرض لهذا قد لا يملك الهامش المالي الكافي لاستيعاب الضربة. اختراق المفاتيح الذي سيُفرغ خزينة كاملة لا مجرد محفظة مكافآت قادم لا محالة، ولن يكون ثغرة في Solidity. بل سيكون مفتاحًا على جهاز كمبيوتر محمول.