ثغرة حرجة في sandbox الخاصة بـ vm2 تسمح للكود غير الموثوق بالهروب إلى المضيف

كشف القائمون على صيانة vm2، وهي مكتبة sandbox شائعة الاستخدام في Node.js، عن ثغرة حرجة قد تسمح لـ JavaScript غير الموثوق بالخروج من sandbox وتنفيذ كود على جهاز المضيف. تُتبع الثغرة بالمعرف CVE-2026-26956، وتؤثر في vm2 الإصدار 3.10.4، وقد ظهرت مع توفر كود exploit لإثبات الفكرة بشكل علني بالفعل.

تكمن أهمية ذلك في أن vm2 تعد من الأدوات القياسية التي يلجأ إليها المطورون عندما يحتاجون إلى تشغيل JavaScript يقدمه المستخدم داخل بيئة يُفترض أنها مقيدة. وهي تظهر في منصات البرمجة عبر الإنترنت، ومنتجات الأتمتة، وأدوات AI، وتطبيقات SaaS التي تسمح للعملاء بتنفيذ scripts. وعندما يقع هروب من sandbox في مثل هذا النوع من البرمجيات، فالمشكلة ليست مجرد خلل نظري أنيق، بل سؤال مباشر عما إذا كان كود المستأجر غير الموثوق يمكن أن يتحول إلى اختراق على مستوى المضيف.

بحسب advisory الصادر عن جهة الصيانة وتقرير BleepingComputer، يرتبط الخلل بالطريقة التي يتعامل بها vm2 مع الاستثناءات العابرة بين sandbox والمضيف. ففي الإعداد المتأثر، يمكن لآلية WebAssembly exception handling تجاوز وسائل الحماية الخاصة بـ vm2 على مستوى JavaScript داخل محرك V8. وهذا قد يسمح بتسرب كائن خطأ من جهة المضيف إلى داخل sandbox، حيث يمكن للمهاجمين إساءة استخدام سلسلة constructor لاستعادة الوصول إلى مكونات Node.js الداخلية مثل process object، ثم تنفيذ أوامر عشوائية على المضيف في النهاية.

هذا التعرض لا ينطبق بالقدر نفسه على كل بيئات Node.js. وتقول advisory إن المشكلة تأكدت على Node.js 25.6.1 في البيئات التي يكون فيها WebAssembly exception handling ودعم JSTag مفعّلين. هذا النطاق التقني مهم، لكنه لا ينبغي أن يخلق شعورا زائفا بالأمان. إذ يجري تنزيل vm2 أكثر من مليون مرة أسبوعيا عبر npm، وغالبا ما تكون مكتبات كهذه مدفونة عميقا داخل منتجات أكبر أو أدوات داخلية أو مزايا توسعة مخصصة للعملاء، وهي أماكن لا تقوم الفرق عادة بحصرها بدقة كافية.

أما التفاصيل الأكثر إلحاحا فهي أن كود exploit أصبح علنيا بالفعل. فعندما يمتلك هروب من sandbox كلا من CVE وإثبات فكرة عام، فإن الفجوة بين الإفصاح والاستغلال الانتهازي تميل إلى الانكماش بسرعة، خصوصا في الخدمات المتصلة بالإنترنت التي تنفذ workflows للمستخدمين أو snippets برمجية أو خطوات أتمتة. وإذا كانت شركة ما تستخدم vm2 لعزل منطق غير موثوق، فعليها أن تفترض أن المهاجمين سيختبرون هذا الحد الآن لا لاحقا.

مسار patch واضح ومباشر. ينبغي للمستخدمين التوقف فورا عن استخدام vm2 3.10.4 والترقية إلى الإصدار 3.10.5 أو أحدث، مع توفر الإصدار 3.11.2 حاليا. لكن patch وحده ليس الاستجابة الكاملة. ينبغي للفرق أيضا تحديد الأماكن التي أُدمج فيها vm2، والتأكد مما إذا كانت إعدادات Node.js 25 المتأثرة مستخدمة بالفعل، ومراجعة أي واجهات في المنتج يمكن للمستخدمين الخارجيين عبرها إرسال كود يصل في النهاية إلى sandbox يعمل بـ vm2.

كما أن هذا الإفصاح ينسجم مع نمط أوسع. فقد تعرض vm2 لعدة ثغرات خطيرة لهروب من sandbox خلال السنوات القليلة الماضية، ما يطرح سؤالا هندسيا صعبا لكنه يزداد أهمية: ما مقدار العزل الحقيقي الذي يمكن أن يوفره sandbox لـ JavaScript عندما يبدأ المهاجمون في العثور على طرق لتجاوز دفاعات مستوى اللغة؟ بالنسبة إلى الفرق التي تبني منصات تعتمد على كود ينفذه المستخدم، أصبح هذا السؤال ذا طابع معماري لا تفصيلا عابرا. وكما أفاد BleepingComputer أولا، فإن الاستجابة الأكثر أمانا هنا لا تقتصر على patch السريع، بل تشمل أيضا إعادة تقييم حجم الثقة الموضوعة في vm2 من الأساس.