محافظ Bloom على Solana (SOL) تفقد 9,408 SOL خلال عملية توقيع استمرت 94 ثانية

تصريف 48 محفظة في 94 ثانية

توقف حلقة التوقيع في خدمة Bloom، وهي خدمة تداول آلية تعمل على شبكة Solana (SOL)، عن العمل فجأة يوم الاثنين، ولم تُؤكد الآلية الدقيقة وراء الخلل بعد. فبين الساعة 01:03 و01:04 بتوقيت غرينتش يوم 26 أكتوبر، أرسلت 48 محفظة مرتبطة بالخدمة مجتمعة 9,408 SOL إلى عنوان خارجي، بحسب بيانات السلسلة. استغرقت التحويلات كلها نحو 94 ثانية من أول عملية إلى آخرها. وقد عُرفت كل محفظة عملات رقمية مصروفة على أنها تنتمي إلى واحد من تسعة مستخدمين للخدمة، إذ تعرّف عليها من خلال سجل دفع رسومها للمنصة.

لم تكن المعاملات نفسها غير عادية في شكلها: فهي تحويلات اعتيادية لعملة SOL على الشبكة الرئيسية لـSolana، وقّعت بمفاتيح المالك الأصلية للمحافظ. لم تكن هناك خطوة موافقة منفصلة يلزم التحايل عليها، ولا توقيع إضافي يلزم تزويره. ومن تمكّن من إنتاج تلك التواقيع كان يملك القدرة على تحويل الأموال بصفته المالك الشرعي، وهو ما وضع سؤال وصول المهاجم إلى المفاتيح قبل أي سؤال عن ضوابط الخدمة الداخلية. توفر Bloom قيدًا على عنوان السحب، بل إن إلغاء القيد عند المستخدم لا يسمح بتغيير العنوان إلا بعد مهلة تمتد 24 ساعة. تلك الضوابط مفيدة عندما يكمن الخطر في اختراق حساب الخدمة أو سحب متعجّل، لكنها لا تساوي شيئًا إذا استطاع طرف من خارج الخدمة التوقيع بالمفاتيح الخاصة مباشرة. لم تُخترق Solana (SOL) ذاتها؛ فالخلل الكمن في إدارة مفاتيح خدمة واحدة، لا في السلسلة التي نفّذت التحويلات.

يُعد سعر Solana (SOL) موضوعًا جانبيًا في هذه القصة؛ فما تحرك هو 9,408 SOL من أرصدة المستخدمين، لا السوق ككل. وقد أعاد الحادث الانتباه إلى الطريقة التي تحتفظ بها روبوتات التداول الآلية بسلطة التصرف في أموال المستخدمين، لأن أي خدمة تضع سلطة توقيع دائمة على محافظ عديدة تتركز لديها نفس درجة التعرض التي ظهرت هنا.

24 محفظة من أصل 48 كانت خاملة

ما يجعل الحادث أوسع من سرقة واحدة هو ضيق نطاق استخدام بعض المحافظ المتضررة. فقد وجد تحليل بيانات السلسلة أن 24 محفظة من أصل 48 لم تدفع أي رسوم تداول لـBloom في الشهر الذي سبق الحادث، وأن خمسًا منها لم تدفع رسومًا منذ الفترة بين يناير ومايو من عام 2025. مستخدمون ابتعدوا عن البوت منذ شهور خسروا أموالهم مع ذلك، لأن محافظهم ظلت مرتبطة بترتيب التوقيع الذي أعدته الخدمة. فالتوقف عن استخدام خدمة تداول آلية لا يلغي التعرض بذاته؛ تبقى سلطة التوقيع قائمة حتى تُستبدل المفاتيح.

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

أما الجانب المالي، فقد أُغلق على الأقل. سددت Bloom تعويضات كامل المستخدمين التسعة المتضررين في يوم الحادث، وأعادت كامل مبلغ 9,408 Solana (SOL) الذي خرج من المحافظ. تلك الدفعة استجابة تقديرية من المشغل، لا مطالبة بتأمين لامركزي، ولا قاعدة تُلزم مشغلًا مستقبليًا بتكرارها. ويبقى مفتوحًا السؤال الذي يكمن تحت التعويض: الطريق الذي حصل به المهاجم على سلطة التوقيع لم يُحدد بعد.

ما الذي يتركه التحليل اللاحق مفتوحًا

امتداد التصميم نفسه هو ما يستحق التدقيق. فأقفال السحب ومهلة الـ24 ساعة بُنيت لإيقاف الأخطاء على مستوى الحساب والتغييرات المتعجلة، لكنها لا تقيّد من يستطيع أصلًا التوقيع بصفته المالك. لذا تمتد فئة الخلل هذه إلى أي نشر يحتفظ بسلطة توقيع دائمة على محافظ المستخدمين، الخاملة منها على وجه الخصوص، إلى أن تُدار المفاتيح. وشرح Bloom لخلل الوحدة هو تشخيص الفريق نفسه لا نتيجة فحص مستقل، ما يجعل مسار الوصول غير المؤكد هو الحقيقة التي يجب مراقبتها. وإذا تسرّبت مادة التوقيع فعلًا، فسيتعين نقل الأرصدة إلى محافظ تُدار بمفاتيح جديدة لمنع سرقة متكررة؛ والمحافظ المادية ذاتية الحفظ مثل Tangem Mobile Wallet أحد تلك المسارات، بينما تحمل الأرصدة الخاملة المرتبطة بالخدمة خطرًا دائمًا إلى أن يتم ذلك النقل.