ترقيع طارئ من Ledger يغلق ثغرة كانت قادرة على إصدار 18.5 تريليون رمز

فيضان الـ18.5 تريليون عبر دفتر الأوامر

لم تمر الثغرة عبر أي باب خلفي، بل عبر دفتر الأوامر نفسه. فالمهاجم كان يستطيع ترتيب عروض بيع وأسعار منتقاة بعناية على البورصة المدمجة في XRP Ledger بحيث يفيض محرك المحاسبة الخاص بمحرك المدفوعات، فتظهر رموز XRP قابلة للإنفاق لم تنشئها الشبكة قط. وكان الحصيلة النظرية، نحو 18.5 تريليون رمز، ستقف أعلى بنحو 185 مرة من سقف الإمداد المتداول الثابت للشبكة البالغ 100 مليار XRP. المهدد هنا لم يكن رقمًا على الشاشة، بل الضمانة الجوهرية للإمداد نفسه: فالرموز المزيفة كانت ستكون قابلة للإنفاق بالكامل، ولمجرد خطأ في العرض، ما جعل السقف نظريًا بلا معنى عمليًا. أغلقت فرق التطوير هذا المسار بترقيع طارئ صدر ضمن الإصدار xrpld 3.4.1 يوم الجمعة 25 سبتمبر.

يرد تقرير الإفصاح الصادر عن مؤسسة XRPL Foundation على مصدر الخلل: كود BookStep، وهو كود التجميع الذي يسعّر العروض عندما يمر الدفع عبر التبادل المدمج في دفتر الأستاذ. فالعروض المرصودة وفق نمط معين كانت تفيض على المحرك وتكسر قاعدة الـXRPNotCreated، وهو الضابط الذي كُتب عام 2017 لمنع نشوء رموز XRP خارج قواعد البروتوكول ذاتها. وقد أثبتت شركة الأمن Veria أن المسار قابل للتطبيق فعليًا، إذ حرّكت الرموز المزيفة عبر سلسلة من عناوين المحافظ مع إبقاء كل حساب تحت سقف الرصيد المفروض لكل حساب على حدة، فلم يظهر أي خلل على حساب منفرد أبدًا. وقدّرت Veria حجم الانكشاف النظري بنحو 94 مليار دولار. أما الجدول الزمني فكان مضغوطًا إلى الحد الأقصى: تأكدت الثغرة يوم الثلاثاء 22 سبتمبر، ودمج الإصلاح في الكود الرئيسي في اليوم التالي، وصدر الإصدار المرقّع الجمعة 25 سبتمبر ضمن xrpld 3.4.1. أي أن التأكيد والدمج والنشر اكتملت جميعها داخل أربعة أيام. ولم يجد تحليل RippleX أثرًا واحدًا لاستخدام الثغرة ضد الشبكة الفعلية. وحظي قرار تجاوز تصويت التعديلات المعتاد باهتمام متجدد يوم الاثنين 12 أكتوبر، حين انتشر إعلان الترقيع الطارئ على منصة X.

لماذا لم يُسأل المدققون عن رأيهم

في الحوكمة الاعتيادية لـXRPL، يصوّت المدققون على تغييرات في معالجة المعاملات على مدى أسابيع قبل دخول أي قاعدة جديدة حيز التنفيذ، فتحصل الشبكة على نقطة تحول واحدة منسقة. والتعديلات المنتظرة حاليًا في قائمة الانتظار تسلك هذا المسار تمامًا. أما هذا الإصلاح فلم يسلكه. فنشر الكود قبل تفعيله كان قد يضع في يد المهاجمين وصفة جاهزة بينما لا تزال غالبية الخوادم تشغّل البرنامج المصاب، ولذلك أصدر المطورون الترقيع مباشرة، وبدأ سريانه على كل خادم فور ترقيته إلى الإصدار 3.4.1.

والاستثناء حمل مخاطره هو الآخر. فأثناء التوزيع، كان الخوادم الموزعة على إصدارات مختلفة قد تعالج معاملة الاستغلال نفسها بطرق متباينة، تاركة الشبكة أمام وجهات نظر متعارضة لدفتر الأستاذ. غير أن هذه النافذة بقيت قصيرة: فعلى حد قياس Veria، تجاوزت نسبة المدققين على الإصدار الجديد 80% بحلول 25 سبتمبر. وجاء القرار بحكم شدة الخلل، لأن انتظار أسبوعين وفق المسار المعتاد كان قد يمنح مهاجمًا زمنًا للعمل بينما تبقى الشبكة مكشوفة. ووضعت الواقعة أيضًا عمر الكود موضع التوثيق: فـBookStep جزء من البرنامج منذ عام 2015، وقاعدة الـXRPNotCreated رافقته منذ عام 2017، أي سنوات قبل أن يكتشف أحد التوليفة التي تكسرهما.

ويغطي تقرير الإفصاح الصادر عن مؤسسة XRPL Foundation الفيضان وقرار النشر دون مسار التعديلات معًا، وهو صريح في أن المطلوب كان استجابة طارئة لتهديد قادر على خلق رموز قابلة للإنفاق تفوق الإمداد الأصلي بكثير، لا قالبًا جديدًا لحوكمة دفاتر الأستاذ. وفي هذا الشهر أيضًا يزن المدققون أسئلة بروتوكولية منفصلة، بينها ما إذا كان يرفع حظر تفويض PaymentBurn بحلول 23 أكتوبر.

سؤال حوكمة يبقى مفتوحًا

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