CVE-2026-48100 in Payy
الملخص
بحسب VulDB • 28/09/2026
Payy هو حل طبقة ثانية (L2) من نوع zk-rollup على شبكة إيثريوم، مصمم للحفاظ على الخصوصية والامتثال للوائح التنظيمية. قبل الإصدار 1.3.0، كانت الدالة `agg_agg` تمرر تدفق الرسائل المضغوط من إثباتاتها الداخلية إلى مصفوفة رسائل عامة: `[Field; 1000]`، لكنها لم تتحقق مطلقاً مما إذا كان الذيل غير المستخدم للمصفوفة الخارجية يساوي صفراً. يمكن لمدقق (prover) مسجل بناء إثبات `agg_final` صالح لحزمة rollup معتمدة عن طريق إدراج رسالة حرق إضافية بعد الرسائل الحقيقية. ثم تقوم الدالة `RollupV1.verifyRollup()` بتحليل ذلك الإدخال العام كحرق عادي ونقل عملات USDC من عقد الـ rollup إلى المهاجم. يُعد هذا فشلاً خطيراً في صحة الدائرة (circuit soundness): حيث يقبل نظام الإثبات بياناً عاماً تكون مصفوفة رسائله غير مشتقة بالكامل من إثباتات داخلية تم التحقق منها. على النشر الحالي، تقتصر دالة `verifyRollup()` على المدقق المدرج ضمن القائمة المسموحة (allowlisted prover)، لذا لا يمكن لمتصل عام جديد تقديم هذا الإثباط الباطل مباشرةً. يحدّ هذا الباب من الوصول إلى طبقة 1 (L1) اليوم؛ لكنه لا يجعل بيان الدائرة سليماً رياضياً. تصبح المشكلة غير مقيدة بالصلاحيات (permissionless) وفقاً لنموذج المدقق الموصوف في ورقة Payy البيضاء. تنص القسم 3.3.2 على: "للانضمام كمدقق، يُطلب من المدقق تقديم رهان صغير"، وينص القسم 3.3.1 أنه إذا فشل مدقق في التقديم، "يمكن للعقد الأخرى تقديم إثبات الحزمة بدلاً منه". في ذلك النموذج، يحتاج المهاجم فقط إلى أن يصبح مدقّقاً مسجلاً واستخدام بيانات موافقة المُصادِق العامة لحزمة تم اعتمادها بالفعل. تمت معالجة هذه المشكلة في الإصدار 1.3.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.