كشفت ثغرة أمنية خطيرة تم اكتشافها حديثاً في Open VSX، وهي سوق للإضافات يستخدم في محررات الأكواد الشهيرة مثل Cursor و Windsurf، بالإضافة إلى النظام البيئي الأوسع المتفرع من VS Code. سمحت هذه الثغرة، المسماة “Open Sesame”، لتطبيق ضار بتجاوز كافة عمليات الفحص الأمني والوصول إلى السوق، مما جعله يبدو وكأنه اجتاز جميع اختبارات السلامة.
وقد تم اكتشاف هذه الثغرة في خط أنابيب الفحص الجديد قبل النشر، والذي تم تصميمه كطبقة أمنية للتحقق من كل إضافة قبل إتاحتها للمستخدمين. وتكمن المشكلة في قيمة إرجاع منطقية واحدة داخل رمز الفحص، مما أدى إلى عدم قدرة النظام على التمييز بين عدم وجود أي ماسحات ضوئية تم إعدادها، أو فشل جميع الماسحات الضوئية في العمل. هذا الارتباك أدى إلى منح التطبيقات الضارة شهادة مرور زائفة.
تفاصيل الثغرة الأمنية في Open VSX
وبحسب فريق “Koi” من المحللين والباحثين، فقد نشأت المشكلة الأساسية من كيفية تعامل النظام مع قيمة إرجاع منطقية واحدة. إذا لم يتم إعداد أي ماسحات ضوئية، أو إذا فشلت جميع الماسحات الضوئية في العمل أثناء عملية الفحص، كان النظام يعيد قيمة “false”. المشكلة هي أن النظام كان يفسر هذه القيمة دائماً على أنها حالة آمنة طبيعية، مما يشير إلى عدم وجود أي إعدادات مطلوبة.
نتيجة لذلك، كان النظام يعتبر أن التطبيق قد اجتاز الفحص بنجاح، وبالتالي يقوم بتفعيله فوراً ليصبح متاحاً للتنزيل العام. هذا السلوك “المرن في حالة الفشل” (fail-open) سمح للتطبيقات الخبيثة بالمرور عبر البوابة الأمنية دون أي تدقيق فعلي، مما يهدد أمن المستخدمين.
آلية استغلال ثغرة Open Sesame
لم تتطلب هذه الثغرة أي وصول خاص أو معرفة داخلية لاستغلالها. كان بإمكان أي شخص لديه حساب ناشر عادي استغلال هذه الفجوة الأمنية ببساطة عن طريق إغراق نقطة نهاية النشر بطلبات تحميل متعددة في نفس الوقت. هذا النوع من الزحام المروري الكثيف كان يؤدي إلى استنزاف تجمع اتصالات قاعدة البيانات، مما يتسبب في فشل مهام الماسحات الضوئية أثناء عملية الإدراج في قائمة الانتظار.
عندما تفشل الماسحات الضوئية في العمل، وبسبب التعامل الخاطئ مع قيمة الإرجاع، كان النظام يضع علامة “تم اجتياز الفحص” على التطبيق. هذا يعني أنه برغم عدم إجراء أي مسح أمني، كان التطبيق يعتبر آمناً ويتم تفعيله للتنزيل.
تجدر الإشارة إلى أن ثغرة Open Sesame قد تم الإبلاغ عنها بشكل مسؤول إلى فريق Open VSX في 8 فبراير 2026. استجاب الفريق بسرعة وقام بإصدار تحديث لإصلاح المشكلة في 11 فبراير 2026، أي بعد ثلاثة أيام فقط من تلقي التقرير.
يوصى المطورون الذين يقومون ببناء خطوط أنابيب فحص مماثلة بضمان التعامل مع حالات الفشل بشكل منفصل عن حالات “لا يوجد شيء للقيام به”. كما يُنصح بشدة بتطبيق تحديد معدل الطلبات على نقاط نهاية النشر لمنع استنزاف تجمع الاتصالات.