CVE-2026-89321 in OpenVSX
الملخص
بحسب VulDB • 14/09/2026
تحدّد إعدادات النشر الحد الأقصى لحجم الملف المضغوط لملف VSIX (ovsx.publishing.max-content_size، 512 ميجابايت افتراضياً)، لكن لا يوجد حدّ لكيفية زيادة حجم الإدخال عند فتحه.
عند أول طلب إلى المسار `/vscode/unpkg/{namespace}/{extension}/{version}/{path}`، يقوم WebResourceService بفتح الإدخال باستخدام `ZipFile.getInputStream()` ثم يمرّر التدفق المفكوك الضغط (decompressed stream) إلى دالة `Files.copy()`. تعمل هذه الدالة حتى نهاية التدفق دون عدّ البايتات المكتوبة. يتم بعد ذلك تخزين النتيجة في ذاكرة التخزين المؤقت تحت المسار المحدد بواسطة متغير النظام `java.io.tmpdir`، وتُزال العناصر من الذاكرة المؤقتة بناءً على عدد الإدخالات (150) وليس الحجم، مما يعني عدم وجود حدّ لاستخدام مساحة القرص.
وبالتالي، يمكن لمُنشئ لديه وصول فقط إلى مساحته الخاصة أن يرفع ملف VSIX صغيراً وقابلاً للضغط بشكل كبير، ما يتسبب في كتابة ملفات أكبر بكثير على نظام الملفات المؤقت للخادم — ويمكن تكرار ذلك باستخدام ملفات أو إصدارات مختلفة، حيث يتم تقديم الطلبات المتكررة من الذاكرة المؤقتة.
الأثر الملاحظ: امتلاء نظام الملفات المؤقت؛ وعادت طلبات الملفات غير المخزنة مسبقاً بـ 500 مع رسالة "No space left on device" (لا توجد مساحة متاحة على الجهاز)؛ وترك استخراج فاشل ملف ذاكرة مؤقتة جزئياً عرّض محاولات لاحقة في ذلك المسار للفشل؛ وفشلت عملية النشر برسالة "Failed to read extension file". ومع ذلك، استمرت البيانات الوصفية والملفات المخزنة مسبقاً في العمل، ولم يتوقف الخادم.
لا يتطلب تشغيل الاستخراج أي مصادقة — فقط الرفع يحتاج إلى مصادقة.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.