تم تعزيز أمان XRPL بعد أن تم حظر عيب تعديل الدفعة على xrpl قبل الشبكة الرئيسية

وقفت مؤسسة XRPL عن مشكلة خطيرة مرتبطة بتعديل الدفعة في xrpl قبل أن تؤثر على الشبكة الرئيسية، مما يبرز تطور وضع الأمان في السجل.

عطل حرج تم اكتشافه أثناء مرحلة التصويت

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

تم اكتشاف المشكلة في 19 فبراير 2026 بواسطة مهندس الأمان براناميا كيشكامات مع أداة Apex المستقلة من Cantina AI. ووفقًا للمؤسسة، لم تكن أموال المستخدمين في خطر لأن التعديل لم يتم تفعيله بعد على شبكة XRPL الرئيسية.

كان التعديل، المعروف رسميًا باسم XLS-56، يهدف إلى إدخال معاملات مجمعة على سجل XRP. كان من شأنه أن يسمح بتجميع عدة معاملات داخلية في دفعة واحدة، مما يحسن الكفاءة والتنسيق. ومع ذلك، كانت تلك المعاملات الداخلية تُترك بدون توقيع عمدًا، مع تفويض التفويض إلى معاملة دفعة خارجية تذكر الموقعين.

كيفية عمل خطأ التوقيع في التحقق

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

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

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

أكدت مؤسسة XRPL أن الاقتراح لم يتم تفعيله وأعادت التأكيد: “كان التعديل في مرحلة التصويت ولم يتم تفعيله على الشبكة الرئيسية؛ لم تكن هناك أموال في خطر.” كان هذا التأكيد حاسمًا للحد من قلق السوق وتسليط الضوء على فائدة الاختبارات الدقيقة قبل التفعيل.

الأثر المحتمل لخطأ تعديل الدفعة

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

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

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

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

وأشارت المنظمة أيضًا إلى المخاطر التي قد تلحق بثقة النظام البيئي الأوسع إذا وصل هذا الاستغلال إلى الشبكة الرئيسية. علق هاري مولاكال، الرئيس التنفيذي لشركتي Cantina وSpearbit: “وجد صائد الأخطاء المستقل لدينا، Apex، هذا الخطأ الحرج.” ثم أعادت فرق Ripple إنتاج السلوك مع إثبات المفهوم وأجرت اختبار وحدة كامل قبل معالجة العيب.

الاستجابة الطارئة وتحديث rippled

بعد الكشف، نُصح مدققو UNL في XRPL على الفور بالتصويت بـ “لا” على اقتراح الدفعة. ضمنت هذه التنسيق أن التعديل لا يمكن أن يتجاوز عتبة التفعيل عن طريق الخطأ أثناء عملية الإصلاح.

تم إصدار نسخة طارئة من البرنامج، rippled 3.1.1، في 23 فبراير 2026. تميز هذه النسخة بشكل صريح كل من تعديل الدفعة الأصلي وتغيير fixBatchInnerSigs كغير مدعومين. وبالتالي، يتم حظرهم من تلقي أصوات المدققين ولا يمكن تفعيلهم على أي شبكة إنتاج.

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

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

تعزيز ممارسات أمان XRPL

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

تنوي المؤسسة زيادة استخدام تدقيقات الشفرة المدعومة بالذكاء الاصطناعي، استنادًا إلى نجاح أدوات Cantina AI ونظام Apex في هذه الحالة. كما ستوسع التحليل الساكن للكشف عن أنماط مثل عودة النجاح المبكرة داخل الحلقات، التي ساهمت في الثغرة في منطق التحقق من الدفعة.

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

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