#XRPLedgerPatchesXRPCreationBug
أصلح XRPL خطأً كان من الممكن أن يُنشئ XRP من لا شيء
كشف خلل أمني في XRP Ledger عن نقطة ضعف خطيرة في أحد أهم ضمانات سلسلة الكتل: منع إنشاء XRP دون تصريح.
وفقًا لتقرير الإفصاح عن الثغرات الأمنية الصادر عن XRPL في 9 أكتوبر 2026، تعلقت المشكلة بتجاوز عدد صحيح أثناء معالجة المدفوعات. وكان من الممكن أن يسمح الخلل لمهاجم بتلقي كمية من XRP أكبر بكثير من المبلغ الذي دُفع فعليًا، ما قد يؤدي إلى إنشاء XRP جديد في أثناء ذلك.
اعتمد الهجوم على مئات الحسابات التي قدمت عروضًا لمبادلة الرموز مقابل XRP. وعندما طابقت دفعة ما عددًا كافيًا من العروض، كان من الممكن أن يتجاوز إجمالي كمية XRP الحد الأقصى لعدد صحيح من 64 بت. وبدلًا من التعامل مع التجاوز بأمان، كان من الممكن أن تلتف نتيجة العملية لتصبح قيمة أصغر بكثير.
أما الجانب المقلق، فهو أن فحص XRPL لسلامة المعروض كان معرضًا أيضًا لتجاوز مماثل، ما قد يسمح بمرور XRP المُنشأ حديثًا من دون اكتشافه.
وبحسب التقارير، أعادت RippleX إنتاج المشكلة في بيئة اختبار بعد أن أبلغ عنها الباحثان Cayden Liao وVeria AI عبر برنامج مكافآت اكتشاف الأخطاء في 22 سبتمبر.
صدر الإصلاح ضمن xrpld 3.4.1، الذي أُطلق في 25 سبتمبر 2026. وأضاف الإصدار عمليات تحقق أكثر صرامة من التجاوز، وحسّن الضمانات المستخدمة للتحقق من سلامة معروض XRP.
أفادت XRPL بأنها لم تعثر على أي دليل على استغلال الخلل في الشبكات العامة.
وهذا التمييز مهم. فقد أظهرت الثغرة طريقةً كان من الممكن أن يُنشأ بها XRP من دون غطاء مناسب، لكن ذلك لا يعني أن XRP إضافيًا قد أُنشئ بالفعل على الشبكة الرئيسية.
في رأيي، تتمثل الخلاصة الأهم في مدى اعتماد الأمور على تفاصيل تبدو صغيرة في العمليات الحسابية لسلاسل الكتل. فتجاوز واحد في منطق المدفوعات قد يقوض قاعدةً خاصة بالمعروض يتوقع المستخدمون أن تفرضها الشبكة بأكملها.
يعالج التصحيح المشكلة المباشرة، لكن الحادثة تذكير أيضًا بأن سلاسل الكتل الراسخة تحتاج إلى مراجعات أمنية مستمرة لمنطق معاملاتها الأساسي.
#XRP #XRPL #BlockchainSecurity
$NEAR $PIXEL $BTC
أصلح XRPL خطأً كان من الممكن أن يُنشئ XRP من لا شيء
كشف خلل أمني في XRP Ledger عن نقطة ضعف خطيرة في أحد أهم ضمانات سلسلة الكتل: منع إنشاء XRP دون تصريح.
وفقًا لتقرير الإفصاح عن الثغرات الأمنية الصادر عن XRPL في 9 أكتوبر 2026، تعلقت المشكلة بتجاوز عدد صحيح أثناء معالجة المدفوعات. وكان من الممكن أن يسمح الخلل لمهاجم بتلقي كمية من XRP أكبر بكثير من المبلغ الذي دُفع فعليًا، ما قد يؤدي إلى إنشاء XRP جديد في أثناء ذلك.
اعتمد الهجوم على مئات الحسابات التي قدمت عروضًا لمبادلة الرموز مقابل XRP. وعندما طابقت دفعة ما عددًا كافيًا من العروض، كان من الممكن أن يتجاوز إجمالي كمية XRP الحد الأقصى لعدد صحيح من 64 بت. وبدلًا من التعامل مع التجاوز بأمان، كان من الممكن أن تلتف نتيجة العملية لتصبح قيمة أصغر بكثير.
أما الجانب المقلق، فهو أن فحص XRPL لسلامة المعروض كان معرضًا أيضًا لتجاوز مماثل، ما قد يسمح بمرور XRP المُنشأ حديثًا من دون اكتشافه.
وبحسب التقارير، أعادت RippleX إنتاج المشكلة في بيئة اختبار بعد أن أبلغ عنها الباحثان Cayden Liao وVeria AI عبر برنامج مكافآت اكتشاف الأخطاء في 22 سبتمبر.
صدر الإصلاح ضمن xrpld 3.4.1، الذي أُطلق في 25 سبتمبر 2026. وأضاف الإصدار عمليات تحقق أكثر صرامة من التجاوز، وحسّن الضمانات المستخدمة للتحقق من سلامة معروض XRP.
أفادت XRPL بأنها لم تعثر على أي دليل على استغلال الخلل في الشبكات العامة.
وهذا التمييز مهم. فقد أظهرت الثغرة طريقةً كان من الممكن أن يُنشأ بها XRP من دون غطاء مناسب، لكن ذلك لا يعني أن XRP إضافيًا قد أُنشئ بالفعل على الشبكة الرئيسية.
في رأيي، تتمثل الخلاصة الأهم في مدى اعتماد الأمور على تفاصيل تبدو صغيرة في العمليات الحسابية لسلاسل الكتل. فتجاوز واحد في منطق المدفوعات قد يقوض قاعدةً خاصة بالمعروض يتوقع المستخدمون أن تفرضها الشبكة بأكملها.
يعالج التصحيح المشكلة المباشرة، لكن الحادثة تذكير أيضًا بأن سلاسل الكتل الراسخة تحتاج إلى مراجعات أمنية مستمرة لمنطق معاملاتها الأساسي.
#XRP #XRPL #BlockchainSecurity
$NEAR $PIXEL $BTC