نقص بحرانی sandbox در vm2 به کد غیرقابل اعتماد اجازه فرار به میزبان را می دهد

نگهدارندگان vm2، کتابخانه پرکاربرد sandbox برای Node.js، یک آسیب پذیری بحرانی را افشا کرده اند که می تواند به JavaScript غیرقابل اعتماد اجازه دهد از sandbox خارج شود و روی ماشین میزبان کد اجرا کند. این نقص با شناسه CVE-2026-26956 پیگیری می شود، vm2 نسخه 3.10.4 را تحت تاثیر قرار می دهد و در حالی منتشر شده که کد exploit اثبات مفهوم آن از قبل به صورت عمومی در دسترس است.

اهمیت این موضوع از آنجاست که vm2 یکی از ابزارهای استانداردی است که توسعه دهندگان هنگام نیاز به اجرای JavaScript ارسالی کاربران در محیطی به ظاهر محدود به سراغش می روند. این کتابخانه در پلتفرم های کدنویسی آنلاین، محصولات اتوماسیون، ابزارهای AI و برنامه های SaaS که به مشتریان اجازه اجرای اسکریپت می دهند دیده می شود. وقتی فرار از sandbox در چنین نرم افزاری رخ می دهد، مسئله فقط یک باگ تئوریک و تمیز نیست. مسئله مستقیما این است که آیا کد غیرقابل اعتمادِ مستاجر می تواند به نفوذ در سطح میزبان تبدیل شود یا نه.

بر اساس advisory نگهدارنده و گزارش BleepingComputer، این باگ به نحوه مدیریت استثناهایی مربوط است که بین sandbox و میزبان جابه جا می شوند. در پیکربندی آسیب پذیر، مدیریت استثنای WebAssembly می تواند از محافظت های سطح JavaScript در vm2 داخل موتور V8 عبور کند. این موضوع می تواند باعث شود یک شیء خطا از سمت میزبان دوباره به sandbox نشت کند، جایی که مهاجمان می توانند از زنجیره constructor سوءاستفاده کنند تا دوباره به اجزای داخلی Node.js مثل process object دسترسی بگیرند و در نهایت فرمان های دلخواه را روی میزبان اجرا کنند.

این در معرض بودن در تمام استقرارهای Node.js یکسان نیست. advisory می گوید این مسئله روی Node.js 25.6.1 در محیط هایی تایید شده که WebAssembly exception handling و پشتیبانی JSTag در آن ها فعال است. این محدوده فنی مهم است، اما نباید احساس امنیت کاذب ایجاد کند. vm2 در npm بیش از یک میلیون بار در هفته دانلود می شود و چنین کتابخانه هایی اغلب در اعماق محصولات بزرگ تر، ابزارهای داخلی یا قابلیت های توسعه پذیری مشتری پنهان می شوند، جاهایی که تیم ها معمولا آن ها را به اندازه کافی دقیق فهرست نمی کنند.

جزئیات فوری تر این است که کد exploit هم اکنون عمومی است. وقتی یک فرار از sandbox هم CVE داشته باشد و هم اثبات مفهوم عمومی، فاصله بین افشا و سوءاستفاده فرصت طلبانه معمولا خیلی سریع کوتاه می شود، به ویژه در سرویس های در معرض اینترنت که workflowهای کاربر، snippetهای کد یا گام های اتوماسیون را اجرا می کنند. اگر شرکتی از vm2 برای ایزوله کردن منطق غیرقابل اعتماد استفاده می کند، باید فرض کند مهاجمان همین حالا این مرز را آزمایش خواهند کرد، نه بعدا.

مسیر patch روشن است. کاربران باید فورا از vm2 3.10.4 خارج شوند و به نسخه 3.10.5 یا بالاتر ارتقا دهند، در حالی که نسخه 3.11.2 اکنون در دسترس است. اما patch کردن به تنهایی کل پاسخ نیست. تیم ها باید همچنین مشخص کنند vm2 در کجاها تعبیه شده، تایید کنند آیا پیکربندی های آسیب پذیر Node.js 25 در حال استفاده هستند، و همه سطوح محصولی را بازبینی کنند که در آن کاربران بیرونی می توانند کدی ارسال کنند که در نهایت به sandbox مبتنی بر vm2 می رسد.

این افشا در عین حال با یک الگوی گسترده تر هم سازگار است. vm2 در چند سال گذشته بارها با باگ های جدی فرار از sandbox مواجه شده است و این موضوع یک پرسش مهندسی دشوار اما هر روز مهم تر را مطرح می کند: وقتی مهاجمان شروع به پیدا کردن مسیرهایی برای دور زدن دفاع های سطح زبان می کنند، sandbox جاوااسکریپت واقعا چه میزان ایزولیشن فراهم می کند؟ برای تیم هایی که پلتفرم هایی بر پایه کد اجرایی کاربران می سازند، این پرسش دیگر یک موضوع فرعی نیست، بلکه جنبه ای معماری پیدا کرده است. همان طور که BleepingComputer نخستین بار گزارش داد، امن ترین پاسخ در اینجا فقط patch سریع نیست، بلکه بازبینی دوباره میزان اعتمادی است که اساسا به vm2 داده شده است.