لم تشتري rsETH من قبل لكن WETH الخاص بك مجمد

مقدمة

النقاط الأساسية:

• تم اكتشاف أربع هجمات بين 13 و19 أبريل 2026، شملت سلاسل Ethereum وUnichain وArbitrum وNEAR، بإجمالي خسائر تقدر بحوالي 310 مليون دولار.
• تشمل طرق الهجوم تسميم بنية RPC الأساسية لـ LayerZero DVN، تزوير إثبات MMR، استغلال الأعداد الصحيحة ذات العلامة في صندوق التأمين، واستغلال مسارات التبادل الدائرية في بروتوكولات الهامش.
• تشير حادثة KelpDAO (290 مليون دولار) إلى أن أمان الجسور عبر السلاسل تجاوز مستوى العقود الذكية، ليشمل البنية التحتية للتحقق خارج السلسلة. كما أن تجميد WETH على خمس سلاسل وتحويل الحالة القسري في Arbitrum يوضح كيف يمكن للتجميع أن يضاعف نقطة فشل واحدة، وأين تقع حدود الثقة الفعلية في أنظمة “لا مركزية”.

خلال الأسبوع الماضي (13/04/2026 - 19/04/2026)، اكتشفت BlockSec وحللت أربع هجمات، بإجمالي خسائر يقدر بـ 310 مليون دولار. يلخص الجدول أدناه هذه الأحداث، وسيتم في الفقرات التالية تحليل كل حادثة بالتفصيل.

الجدول 1: نظرة عامة على الأربع هجمات التي تم اكتشافها هذا الأسبوع

نقطة التركيز لهذا الأسبوع: KelpDAO

تم اختيار حادثة KelpDAO كنقطة تركيز لهذا الأسبوع لأنها تقدم طرق هجوم جديدة على البنية التحتية (تسميم RPC الخاص بـ DVN الوحيد، بدلاً من استغلال ثغرات العقود الذكية)، وتأثيرات متسلسلة عبر السلاسل ناتجة عن التفاعلات بين DeFi، بالإضافة إلى مشكلة الحوكمة التي أثارتها عملية التحويل القسري لاسترداد الأموال المسروقة في Arbitrum.

في 18 أبريل 2026، تم هجوم على جسر KelpDAO rsETH LayerZero OFT عبر الجسر العابر للسلاسل، وخسارة حوالي 290 مليون دولار. نسب فريق LayerZero Labs هذا الهجوم إلى جهة هجوم مدعومة من الدولة، ربما مجموعة Lazarus الكورية الشمالية [1]. السبب الجذري هو أن تكوين DVN الخاص بـ KelpDAO هو واحد من واحد (1-of-1)، مما يقلل من التحقق من الرسائل عبر السلاسل إلى نقطة فشل واحدة. قام المهاجم بتسميم البنية التحتية لـ RPC الموثوقة لـ LayerZero Labs، مما أجبرها على توقيع إثبات رسالة عبر السلسلة مزورة، مما أدى إلى إصدار 116,500 rsETH على إيثريوم، رغم عدم وجود حدث إرسال مقابل على السلسلة المصدر (Unichain).

خلفية

LayerZero هو بروتوكول رسائل عبر السلاسل يعتمد على بنية أمان معيارية. يضمن سلامة الرسائل عبر السلاسل شبكة من المدققين اللامركزية (DVN)، وهي كيانات خارج السلسلة مسؤولة عن التحقق المستقل من صحة الرسائل المرسلة من السلسلة المصدر قبل السماح بتنفيذها على السلسلة الهدف. كل تطبيق يُنشر على LayerZero يضبط إعدادات DVN الخاصة به، بما يشمل الثقة في أي DVN، وعدد DVN المطلوب للموافقة، وعامل الإجماع. تتيح هذه البنية المعيارية للتحكم الكامل في نموذج الأمان، لكن تتحمل مسؤولية كاملة: ضعف التكوين لا يمكن أن تغطيه البروتوكولات ذاتها.

يعمل KelpDAO rsETH كرمز قابل للاستبدال عبر السلسلة (OFT) على LayerZero، ويربط بين Unichain (السلسلة المصدر) وإيثريوم الرئيسي (السلسلة الهدف). يسمح معيار OFT بحرق الرموز على السلسلة المصدر وإصدارها على السلسلة الهدف من خلال رسالة عبر السلسلة، وتعد الرسالة عبر السلسلة هي الإذن الوحيد بالإصدار. على جانب إيثريوم، يتولى موصل (0x85d456…e98ef3) إصدار rsETH للمستلم بعد التحقق من الرسالة عبر السلسلة ونقلها. المشكلة الأساسية أن KelpDAO ضبط هذا المسار ليكون 1-of-1 DVN، مع تعيين LayerZero Labs كمحقق وحيد. هذا يعني أن إثبات DVN واحد يمكن أن يخول إصدار أي رموز، دون حاجة لموافقة طرف ثاني.

لتنفيذ مسؤولية التحقق، يستعلم DVN الخاص بـ LayerZero Labs عن عدة عقد RPC، للتحقق من أن حدث الإرسال عبر السلسلة حدث على السلسلة المصدر. تشمل هذه العقد البنية التحتية التي تديرها الشركة ومزودين خارجيين، ويعتمد DVN على استجابتهم الجماعية لتوقيع الإثبات. تكاملية هذه العملية تعتمد على فرضية أن غالبية العقد المستعلم عنها تعود ببيانات حقيقية.

تحليل الثغرة

هذه الثغرة ناتجة عن فشل منهجي في البنية التحتية والإعداد، تتكون من ثلاث نقاط ضعف متراكبة:

1. تكوين DVN واحد من واحد (1-of-1) يلغي وجود تكرار في طبقة التحقق. توصي LayerZero بإعدادات أمان متعددة DVN مع مدققين مستقلين لضمان أن لا يمكن لـ DVN واحد فقط أن يخول رسالة. الاعتماد على DVN واحد من قبل KelpDAO يعني أن أي اختراق لهذا المدقق يمكن أن يخول إصدار رموز عشوائي.
2. آلية الانتقال الفاشل (failover) في DVN تعتمد على توجيه استعلامات التحقق إلى أي عقد RPC متاحة. هذا التصميم يفترض أن تعطل العقدة هو حالة عارضة، وليس هجوم متعمد. لكن، يخلق هذا شرطًا حيث يمكن للمهاجم أن يوقف عقدة صحية عبر هجمات DDoS، ويجهز عقدة ملوثة كبديل وحيد متاح، مما يمكنه من السيطرة الكاملة على البيانات التي يتلقاها DVN.
3. استبدال ملف op-geth على عقد RPC يتطلب وصولاً لنظام التشغيل على الخادم الأساسي. لم يُكشف عن تفاصيل الوصول الأولي، لكن اختراق عقدتين على مجموعتين مستقلتين يشير إلى وجود ضعف مشترك في التحكم بالوصول.

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

تحليل الهجوم

التحليل التالي يستند إلى المعاملة 0x1ae232…4222 وبيان رسمي من LayerZero Labs.

الخطوة 1: حصل المهاجم على قائمة عقد RPC الموثوقة من قبل DVN الخاص بـ LayerZero Labs، مما يشكل هدفًا ذا قيمة عالية، إذ أن معرفة العقد المحددة يمكن المهاجم من التخطيط لعمليات دقيقة بدلاً من هجمات بنية تحتية عشوائية.
الخطوة 2: حصل المهاجم على صلاحيات كتابة على عقدتين RPC، واستبدل ملف op-geth قيد التشغيل بنسخة خبيثة. هاتان العقدتان تعملان على مجموعتين مستقلتين، مما يشير إلى أن الوصول الأولي ربما كان عبر اعتماد مشترك (مثل تسريب شهادات النشر، خطوط CI/CD، أو هجمات هندسة اجتماعية على فريق التشغيل). لم تكشف LayerZero Labs عن طريقة الوصول الدقيقة. هذه الخطوة ضرورية لتمهيد التلاعب بالبيانات لاحقًا.
الخطوة 3: نفذ الملف الخبيث من نوع op-geth منطق استجابة موجهة: يرد فقط على طلبات DVN من عناوين IP الخاصة به ببيانات معاملات مزورة، ويقدم في الوقت نفسه الحالة الحقيقية للسلسلة على باقي الطلبات، بما يشمل أدوات المراقبة، متصفحات الكتل، وخدمات المسح. هذا التسميم الانتقائي يجعل الهجوم غير مرئي لأنظمة الرصد، ويبدو أن السلسلة المصدر تعمل بشكل طبيعي من وجهة نظر خارجية.
الخطوة 4: يتطلب توافق DVN الداخلي أن تتفق العقدة الملوثة والعقد غير المهاجمة على البيانات المستلمة. لحل هذا التناقض، يشن المهاجم هجمات DDoS على العقد الصحية خلال نافذة الهجوم (من 10:20 إلى 11:40 بتوقيت المحيط الهادئ)، مما يثير آلية الانتقال الفاشل في DVN، ويجبرها على الاعتماد كليًا على البنية التحتية الملوثة. هذه الخطوة ضرورية، لأن العقد الصحية ستعيد بيانات حقيقية تتعارض مع الرد المزور إذا لم يتم ذلك.
الخطوة 5: بعد ذلك، يُعرض على DVN رسالة عبر السلسلة مزورة من قبل المهاجم، وتُثبت على أنها صحيحة. يُظهر DVN على هدف إيثريوم أن nonce هو 308، بينما لا توجد حدثات إرسال مقابلة على Unichain (الهدف يُظهر أن nonce الخارجي هو 307).
الخطوة 6: بعد التحقق، يرسل موصل rsETH على إيثريوم 116,500 rsETH إلى عنوان المستلم الخاص بالمهاجم (0x8b1b6c…0d3b)، والذي تم تمويله مسبقًا عبر Tornado Cash قبل ساعات. تُنقل الرموز المسروقة إلى سبعة محافظ فرعية، وتُستخدم عبر رهن أصول على Aave، وتحويل مباشر إلى ETH، وعبور السلسلة إلى Arbitrum للتصفية، وتُجمع الأرباح في النهاية على عناوين على إيثريوم وArbitrum.
الخطوة 7: بعد تنفيذ الملف الخبيث، يُشغل عملية تدمير ذاتي، تحذف نفسها وجميع السجلات المحلية، مما يصعب التحقيق بعد الهجوم، ويظهر مستوى احترافية عالي من المهاجم.
الخطوة 8: يحاول المهاجم تكرار نفس المسار لاستهداف 40,000 rsETH إضافية (حوالي 95 مليون دولار)، لكن تم اكتشاف ذلك من قبل KelpDAO وإيقاف جميع العقود ذات الصلة على إيثريوم وL2. [2]

تأثيرات أوسع

الأضرار لا تقتصر على ثغرة جسر LayerZero في البداية. استودع المهاجم حوالي 89,567 rsETH (حوالي 221 مليون دولار) في عدة أسواق عبر منصة Aave، بقرض WETH بنسبة 93% LTV باستخدام وضع E-Mode ###. نظرًا لعدم قدرة Aave على التمييز بين rsETH الشرعي و الرموز المزورة التي أُطلقت عبر الرسائل المزورة، فإن الضمانات “السامة” تعتبر سليمة تمامًا. أدى ذلك إلى تجميد احتياطيات WETH، وانتقال التجميد عبر إيثريوم إلى Arbitrum وBase وMantle وLinea، مما يؤثر على مستخدمين لم يتعاملوا مع rsETH من قبل. هذا الانتشار المتسلسل، من خلل في تكوين الجسر إلى تعطيل أسواق DeFi، يوضح كيف يمكن للتجميع أن يضاعف نطاق وتكلفة نقطة فشل واحدة.

كما أثارت الحادثة أسئلة مهمة حول واقع التشغيل اللامركزي. أعلنت LayerZero Labs أن DVN لن يوقع بعد الآن على تطبيقات تستخدم تكوين 1-of-1، مما يشير إلى أن الاعتماد على اللامركزية في البروتوكول لا يعوض عن عيوب التكوين على مستوى التطبيق.

على مستوى السلسلة، نفذت لجنة أمان Arbitrum إجراءً طارئًا بتجميد 30,766 ETH من عناوين المهاجم على Arbitrum One. وفقًا لتحليل BlockSec، تم ذلك عبر تنفيذ حالة قسرية على مستوى السلسلة: قامت اللجنة بترقية مؤقتة لعقد inbox الخاص بـ إيثريوم، وأدخلت رسالة بدون توقيع من عنوان المهاجم، ثم أعادت تنفيذ العقد الأصلي، دون الحاجة لتوقيع المالك $290M .

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

الاستنتاج

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

ثلاث تدابير تخفيف يمكن أن تمنع هذا الهجوم بشكل فردي:

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

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

المراجع

[4] LayerZero Labs، “بيان حادثة KelpDAO”، 20 أبريل 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[1] KelpDAO، “السياق الإضافي لحادث 18 أبريل”، 21 أبريل 2026. https://x.com/KelpDAO/status/2046332070277091807

[5] Arbitrum، “إجراء الطوارئ لمجلس الأمان”، 21 أبريل 2026. https://x.com/arbitrum/status/2046435443680346189

[3] LlamaRisk، “تقرير حادثة rsETH”، 20 أبريل 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[1] BlockSec، “تحليل آلية التجميد لمجلس أمان Arbitrum”، 21 أبريل 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

حوادث أخرى هذا الأسبوع

Hyperbridge

في 13 أبريل 2026، تعرض Hyperbridge، جسر رسائل عبر السلسلة يعتمد على إيثريوم، لهجوم بسبب نقص التحقق من الإدخال في منطق إثبات MMR، وخسائر تقدر بـ 242 ألف دولار. لم يُفرض على وظيفة MerkleMountainRange.VerifyProof[2][3] التحقق من أن leaf_index أصغر من leafCount، مما سمح للمهاجمين بتزوير إثباتات عبر السلسلة وتنفيذ عمليات ذات امتيازات، بما في ذلك إصدار 1,000,000,000 من رموز DOT.

[4] خلفية

Hyperbridge يستخدم نموذج المدققين والمنسقين على جانب إيثريوم لمعالجة الرسائل عبر السلسلة. على إيثريوم، يتحقق عقد HandlerV1 من صحة الإثبات باستخدام overlayRoot المخزن، وإذا تم قبوله، يوزع الرسالة على الوحدة المستهدفة، مثل عقدة TokenGateway.

عقدة TokenGateway هي وحدة إدارة أصول ذات امتيازات، تدعم عمليات الجسر العادية والإدارية، مثل إنشاء الأصول، إلغاؤها، وإدارة المدراء. بالنسبة للأصول المربوطة عبر ERC6160Ext20، يمكن للمديرين نقل صلاحية الإصدار مباشرة عبر وظيفة changeAdmin[5](، ثم يمكنهم إصدار رموز غير محدودة عبر وظيفة mint)###.

يعتمد أمان الجسر على صحة مسار التحقق من الإثبات في HandlerV1. إذا تم تزوير الرسائل، فإن الوحدات الفرعية ستعتبر الأوامر حقيقية، مما يهدد الأصول.

( تحليل الثغرة

المشكلة تتعلق بمنطق التحقق من الإثبات في HandlerV1 (0x6c84ed…6d64). الدالة handlePostRequests)(، عند بناء MmrLeaf)، تستخدم leaf.kIndex وleaf.index وcommitment###، ثم تستدعي MerkleMountainRange.VerifyProof().

لكن، VerifyProof( لا يتحقق من أن leaf.index أصغر من leafCount، بل يكتفي بمقارنة الجذر مع نتيجة حساب الجذر. هذا يسمح للمهاجمين باستخدام leaf.index يساوي leafCount (مثل 1 عندما يكون leafCount=1)، مما يجعل إثباتات مزورة تمر، ويكسر الربط بين الرسالة والإثبات، ويجعلها مقبولة رغم أنها لم تكن جزءًا من الشجرة الأصلية.

![])https://img-cdn.gateio.im/social/moments-b2403df3c2-75af16b47f-8b7abd-badf29(

رسم توضيحي: جزء من كود VerifyProof يفتقر إلى التحقق من حد leaf_index

) تحليل الهجوم

التحليل التالي يستند إلى المعاملة 0x240aeb…1109.

الخطوة 1: قام المهاجم EOA 0xC513…F8E7 بنشر عقد مساعد 0x518A…8f26 و0x31a1…ca9AB في نفس المعاملة.
الخطوة 2: عبر استغلال الثغرة، قدمت العقدة 0x31a1…ca9AB طلبًا مزورًا عبر HandlerV1، حيث لم يتم رفض leaf_index يساوي leafCount، مما سمح للطلب المزور أن يُدرج في الشجرة ويُعتبر صحيحًا.
الخطوة 3: بعد قبول الطلب المزور، يُرسل إلى TokenGateway، ويُنفذ تغيير مدير الأصول (ChangeAssetAdmin)، مما يغير إدارة DOT إلى عقدة المهاجم 0x31a1…ca9AB.
الخطوة 4: قام المهاجم بإنشاء 1,000,000,000 من رموز DOT.
الخطوة 5: استخدم المهاجم Odos Router V3 لتحويل الرموز المصدرة حديثًا إلى ETH بقيمة 108.2 ETH.
الخطوة 6: نقل المهاجم 108.2 ETH إلى حسابه الخاص.

الاستنتاج:

هذه الحادثة ناتجة عن عدم التحقق الصحيح من حد leaf_index في منطق إثبات MMR في HandlerV1. عدم التحقق من أن leaf_index أصغر من leafCount يسمح للمهاجمين بتقديم إثباتات مزورة تمر عبر التحقق، رغم أنها لم تكن جزءًا من الشجرة الأصلية، مما يتيح لهم تنفيذ عمليات غير مصرح بها. الحل هو فرض التحقق من أن leaf_index < leafCount قبل قبول الإثبات.

المراجع:

( BlockSec، “تحليل هجوم Hyperbridge”، 13 أبريل 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

في 13 أبريل 2026، تعرض Dango، منصة تداول عقود دائمة على Cosmos AppChain، لهجوم بسبب نقص التحقق من الرموز ذات العلامة، وخسائر تقدر بـ 1.5 مليون دولار. تستخدم وظيفة replenish_insurance_fund)(، التي تستخدم is_non_zero)( بدلاً من is_positive)(، للتحقق من المدخلات، مما يسمح للمهاجمين بتقديم قيمة USDValue سالبة ونقل صندوق التأمين إلى مراكز ضمانهم.

) خلفية

Dango هو منصة عقود دائمة على Cosmos، حيث يودع المستخدمون USDC كضمانات، ويفتحون مراكز ذات رافعة مالية على أصول مثل BTC وETH وSOL عبر دفتر أوامر مركزي على السلسلة. تتبع رصيد الضمانات للمستخدمين كحسابات ضمان داخل العقود.

للحماية من الخسائر، يدير البروتوكول صندوق تأمين، يُخزن فيه USDC من المستخدمين، ويُستخدم لتغطية الفروقات عند تصفية مراكز لا تفي بالضمانات. أي مستخدم يمكن أن يساهم في الصندوق عبر حسابه.

( تحليل الثغرة

المشكلة تكمن في وظيفة 0x90bc84…bea4f، التي لا ترفض المدخلات السالبة. هناك فحصان، لكنهما لا يمنعان المدخلات السالبة:

• ensure!)amount.is_non_zero###[1](، يتحقق فقط من أن المبلغ غير صفري، وليس إيجابيًا.
• ensure!)user_state.margin >= amount###، يتحقق من أن الهامش أكبر من أو يساوي المبلغ، وهو صحيح حتى لو كان المبلغ سالبًا.

عند تنفيذ العملية، يتم استخدام checked_sub_assign[1] وchecked_add_assign(، وإذا كانت القيمة سالبة، فإن ذلك يزيد من هامش المستخدم ويقلل من صندوق التأمين، عكس المنطق المقصود.

![])https://img-cdn.gateio.im/social/moments-bfbc4f9ac0-5d013c5828-8b7abd-badf29(

رسم توضيحي: وظيفة replenish_insurance_fund تفتقر للتحقق من العلامة

) تحليل الهجوم

المعاملات:

المرحلة 1:

يودع المهاجم USDC بقيمة 1 مليون لفتح مركز ضمان، عبر استدعاء replenish_insurance_fund().

المرحلة 2:

يستدعي المهاجم replenish_insurance_fund###### مع قيمة سالبة (-1.5 مليون). بسبب عدم التحقق، يُقبل المبلغ السلبي، ويُنقل USDC من صندوق التأمين إلى مركز ضمان المهاجم.

المرحلة 3:

يستخرج المهاجم كامل الرصيد من مركز الضمان، ويحصل على 1.5 مليون USDC.

المرحلة 4-8:

يُكرر المهاجم عملية نقل الأصول عبر الجسور إلى إيثريوم، حيث يُنقل حوالي 410 ألف USDC.

الاستنتاج:

الهاجم هو أن الثغرة تكمن في استخدام نوع عدد صحيح ذو علامة (signed) في سياق غير موقع، مع عدم وجود حماية للعلامة. وظيفة التبرع لصندوق التأمين تعتمد على أن المبلغ موجب، لكن باستخدام is_non_zero() بدلاً من is_positive((، يمكن للمهاجم أن يغير اتجاه التدفق المالي، ويحول USDC من صندوق التأمين إلى مركز ضمانه.

Rhea Finance

في 16 أبريل 2026، تعرض بروتوكول Rhea Finance على NEAR، وهو منصة اقتراض وتداول هامش، لهجوم بسبب خلل في منطق العمل، وخسائر تقدر بـ 18.4 مليون دولار. عند فتح مركز هامش، يعتمد البروتوكول على verify_token_out)) للتحقق من مخرجات التبادل المتوقعة قبل قبول المركز. لكن، الدالة تُجمع بشكل خاطئ لقيم token_out الوسيط، وتفترض أن كل قيمة من هذه المخرجات ستُحتسب في النهاية، رغم أن بعض هذه القيم تُستخدم لاحقًا كمدخلات في عمليات أخرى، مما يسمح للمهاجمين بإنشاء مسارات تبادل حلقية، وتضخيم قيمة المخرجات المعلنة، والتجاوز على حدود القدرة على السداد، وسحب حوالي 18.4 مليون دولار.

( خلفية

Burrowland هو بروتوكول مفتوح المصدر على NEAR، يدعم الإقراض والتداول بالهامش، ويحتوي على ثلاثة متغيرات رئيسية لتمثيل مراكز الرافعة المالية: token_c (الضمان)، token_d (الأصل المقترض)، و token_p (الأصل المفتوح).

بالنسبة للمراكز الطويلة، يودع المستخدمون token_c ويقترضون token_d، ثم يبدلونها في DEX للحصول على token_p، بهدف التعرض للأصل. بشكل طبيعي، قيمة token_p يجب أن تساوي قيمة token_d التي تم إنفاقها.

بالنسبة للمراكز القصيرة، يودع المستخدمون token_c ويقترضون token_d، ثم يبدلونها إلى أصل آخر، مما يخلق تعرضًا قصيرًا على token_d.

خلال حياة المركز، يُحتفظ token_p من قبل البروتوكول، ولا يمكن للمستخدمين سحبها مباشرة. يجب إغلاق المركز لتحقيق الأرباح أو الخسائر، حيث يُبدل token_p مرة أخرى إلى token_d لسداد الدين.

يتم فتح مراكز الهامش عبر internal_margin_open_position)(، التي تضبط المعلمات وتوزع القروض إلى DEX.

![])https://img-cdn.gateio.im/social/moments-084491e5bb-d203f16753-8b7abd-badf29(

رسم توضيحي: وظيفة internal_margin_open_position

قبل أن يقبل البروتوكول مركزًا جديدًا، يقيم أربع حماية:

• is_min_amount_out_reasonable)(، يقارن min_token_p_amount المعلن من المستخدم مع الناتج المقدر من قبل Pyth، لتقييد الانزلاق السعري.
• is_open_position_liquidatable)###، يتحقق من أن قيمة المركز والأصول تظل فوق حد التصفية.
• is_open_position_forcecloseable###(، يتحقق من أن المركز غير مفلس.
• get_open_position_lr)(، يفرض أن نسبة token_d إلى token_c لا تتجاوز الحد الأقصى للرافعة.

جميع الفحوصات تستخدم min_token_p_amount، لأنه لم يتم تنفيذ التبادل بعد، ولا توجد قيمة فعلية. لذا، تعتمد صحة كل فحص على ارتباط min_token_p_amount مع كمية التبادل الفعلية التي ستُسلم من قبل DEX، وهو ما يجب أن يتحقق عبر verify_token_out)(.

![])https://img-cdn.gateio.im/social/moments-5d0de6737a-27b31cb2f8-8b7abd-badf29(

رسم توضيحي: وظيفة verify_token_out وفحص القدرة على السداد

) تحليل الثغرة

المشكلة تكمن في داخل verify_token_out()، حيث تختار القيمة token_out من آخر خطوة تبادل، وتجمع min_amount_out لكل خطوة تنتج نفس الرمز، وتفترض أن كل هذه القيم تساهم في القيمة النهائية. هذا صحيح في التبادلات متعددة المسارات (مقسمة)، لكن لا يراعي أن بعض هذه token_out تُستخدم كمدخلات في خطوات لاحقة، وتُستهلك داخل المسار، خاصة في مسارات حلقية مثل A->B->A->B، حيث يُحتسب كل خطوة على أنها مساهمة في المجموع، رغم أن الناتج النهائي لا يُصل إلى البروتوكول.

هذا يؤدي إلى تضخيم قيمة min_amount_out المعلنة، مما يجعل جميع فحوصات القدرة على السداد غير دقيقة، ويُقبل المركز بناءً على بيانات زائفة، ويُوزع الدين على DEX بشكل غير آمن.

![]###https://img-cdn.gateio.im/social/moments-2cf6bed575-bf31deedff-8b7abd-badf29(

رسم توضيحي: جزء من كود verify_token_out يفتقر للتحقق من حد leaf_index

) تحليل الهجوم

التحليل التالي يستند إلى المعاملة 0x240aeb…1109.

المرحلة 1: قام المهاجم 0xC513…F8E7 بنشر عقد مساعد 0x518A…8f26 و0x31a1…ca9AB في نفس المعاملة.
المرحلة 2: عبر استغلال الثغرة، قدمت العقدة 0x31a1…ca9AB طلبًا مزورًا عبر verify_token_out()، حيث لم يتم التحقق من أن leaf_index أصغر من leafCount، مما سمح للطلب المزور أن يُدرج في الشجرة ويُعتبر صحيحًا.
المرحلة 3: بعد قبوله، يُرسل إلى TokenGateway، ويُنفذ تغيير مدير الأصول، ويُغير إدارة DOT إلى عقدة المهاجم 0x31a1…ca9AB.
المرحلة 4: أنشأ المهاجم 1 مليار من رموز DOT.
المرحلة 5: استخدم المهاجم Odos Router V3 لتحويل الرموز إلى ETH بقيمة 108.2 ETH.
المرحلة 6: نقل المهاجم ETH إلى حسابه الخاص.

الاستنتاج:

الثغرة ناتجة عن عدم التحقق من أن leaf_index أصغر من leafCount في منطق إثبات MMR في HandlerV1. عدم التحقق يسمح للمهاجمين بتقديم إثباتات مزورة تمر عبر التحقق، رغم أنها لم تكن جزءًا من الشجرة الأصلية، مما يمكنهم من تنفيذ عمليات غير مصرح بها. الحل هو فرض التحقق من أن leaf_index < leafCount قبل قبول الإثبات.

المراجع:

( BlockSec، “تحليل هجوم Hyperbridge”، 13 أبريل 2026. https://x.com/Phalcon_xyz/status/2043601549893738970