ظهر منشور XRPL تصلح ثغرة حرجة قبل الشبكة الرئيسية، لكن تطبيقات العملاء لا تزال معرضة للخطر على BitcoinEthereumNews.com.
وضع مدققو XRP Ledger (XRPL) تعديل BatchV1_1 على مسار شرطي للتفعيل عند الساعة 14:06:41 بالتوقيت العالمي المنسق في 29 سبتمبر، مما يحول حادثة أمنية كادت تقع إلى اختبار حي لعملية التعديل في الشبكة والبرمجيات المحيطة بها. في 22 سبتمبر، أظهر xrpldashboard أن 30 من 35 مدققًا موثوقًا يدعمون التعديل، وهو أعلى من عتبة 28 صوتًا المعروضة. ظهرت الأغلبية لأول مرة على السجل في 15 سبتمبر. وفقًا لقواعد التعديل في XRPL، يجب أن يبقى الدعم أعلى من 80% لمدة أسبوعين. أي انخفاض إلى 80% أو أقل ينهي فترة الأغلبية، لذا يبقى تاريخ التفعيل شرطيًا. يُعد 29 سبتمبر أول اختبار إنتاجي لما إذا كانت عملية المدققين في XRPL والتنفيذ المرجعي والنظام البيئي للعملاء قد حوّلت ثغرة خطيرة قبل الشبكة الرئيسية إلى بنية تحتية قابلة للاستخدام للمعاملات الذرية. عمل جدار الحماية الخاص بالمدققين قبل الشبكة الرئيسية لم يُفعَّل تعديل Batch الأصلي أبدًا على الشبكة الرئيسية لـ XRP Ledger. في فبراير، وجد الباحثون ثغرة تصريح حرجة بينما كان التعديل لا يزال في مرحلة التصويت، ونُصح المدققون بالتصويت ضده. تنص إفصاح XRPL Labs الرسمي عن الثغرة على أنه لم تكن هناك أموال معرضة للخطر. كانت الثغرة تكمن في الحلقة التي تتحقق من الحسابات التي تصرّح بدفعة. إذا صادف الكود موقّعًا لحساب منشأ حديثًا يتطابق مفتاحه مع ذلك الحساب، فإنه يعيد النجاح فورًا بدلًا من المتابعة عبر الموقّعين المتبقين. يمكن للمهاجم وضع ذلك الموقّع الصالح أولًا، ثم إضافة إدخال مزوّر يدّعي التصريح بحساب ضحية. لو كان التعديل قد أصبح فعّالًا، لكانت معاملة الضحية غير المفحوصة قد نُفذت دون مفاتيح الضحية. جاء رد XRPL على مرحلتين. الإصدار 3.1.1 وسم تعديلي Batch الأصلي وfixBatchInnerSigs كغير مدعومين، مما منع تفعيلهما. استبدل BatchV1_1 لاحقًا كليهما بمسار تصريح معاد كتابته ودفاعات إضافية. كانت الحادثة فشلًا تم اكتشافه عند الحدود بين إصدار البرمجيات وتفعيل البروتوكول. مواصفة XLS-56 النهائية لمؤسسة XRPL الآن…