CVE-2026-48702 in Rekor
الملخص
بحسب VulDB • 13/08/2026
Rekor هو سجل شفافية لسلسلة توريد البرمجيات. بدءاً من الإصدار 0.3.0 وحتى قبل الإصدار 1.5.2، تقوم الدالة `Package.Unmarshal()` الموجودة في الملف `pkg/types/alpine/apk.go` بفك ضغط أعضاء التوقيع والتحكم (gzip) الخاصين بملف APK إلى مخازن مؤقتة داخل الذاكرة دون تحديد حجم إجمالي مفكوك الضغط. فحص `max_apk_metadata_size` الحالي (الافتراضي 1 ميجابايت) يُطبق فقط على أحجام رؤوس عناصر tar الفردية بعد اكتمال فك الضغط، وبالتالي لا يمنع "قنبلة فك الضغط" من استهلاك ذاكرة عشوائية غير محدودة. يمكن لمهاجم إنشاء تدفق gzip يتم ضغطه بنسبة ~1000:1 (على سبيل المثال، 2 ميجابايت من الأصفار المضغوطة → 2 جيجابايت مفكوك الضغط). عند إرساله كـ `spec.package.content` في إدخال مقترح (`ProposedEntry`) لنظام Alpine، يقوم الخادم بفك ضغط الحمولة الكاملة إلى الذاكرة أثناء معالجة الطلب، مما يؤدي إلى حدوث خطأ حرج في وقت تشغيل Go بسبب نفاد الذاكرة (out-of-memory) أو عملية قتل من قبل نظام التشغيل (OOM-kill) لا يمكن اعتراضها بواسطة وسيط الاستعادة (`recover()`) الخاص بالخادم. هذه الثغرة قابلة للاستغلال عبر نقطتي نهاية غير مصادق عليهما، وهما `POST /api/v1/log/entries` (createLogEntry) و `POST /api/v1/log/entries/retrieve` (searchLogQuery). كلاهما يستدعي الدالة `V001Entry.Canonicalize()` → `fetchExternalEntities()` → `apk.Unmarshal(packageData)`، والتي تقوم بفك الضغط غير المحدود. يصحّح الإصدار 1.5.2 هذه الثغرة. لا يوجد حل بديل فعال. يؤدي تعيين `max_request_body_size` إلى تقليل التعرض للخطر ولكن ليس القضاء عليه تماماً بسبب نسبة الضغط ~1000:1 (حيث يسمح حد حجم الجسم البالغ 1 ميجابايت بتخصيص ما يقارب 1 جيجابايت من الذاكرة العشوائية). لا يؤثر تعيين `max_apk_metadata_size` على هذه الثغرة نظراً لتطبيق الفحص بعد فك الضغط.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.