خلاصه: پژوهش امنیتی GitLab در ۲ سپتامبر ۲۰۲۶ یک مسیر بحرانی فرار از Sandbox در کتابخانه vm2 را تشریح کرد که میتواند کد غیرقابلاعتماد را از محیط ایزوله خارج کرده و به اجرای فرمان روی میزبان منجر کند. اگر سرویس Node.js شما از vm2 برای اجرای کد کاربران، پلاگینها یا اسکریپتهای ناشناس استفاده میکند، این موضوع را یک ریسک سطح میزبان در نظر بگیرید: نسخه و وابستگیها را فوراً بررسی کنید، اجرای کد غیرقابلاعتماد را متوقف یا به ایزولیشن قویتر منتقل کنید و دسترسی پردازش را حداقلی نگه دارید.
vm2 چیست و چرا این آسیبپذیری مهم است؟
vm2 یک کتابخانه Node.js برای اجرای JavaScript غیرقابلاعتماد در یک محیط محدودشده است. مسئله اصلی در کلاس آسیبپذیریهای Sandbox Escape این است که مرز اعتماد میشکند؛ یعنی کدی که قرار بوده فقط داخل محیط محدود اجرا شود، میتواند به قابلیتهای میزبان نزدیک شود. در سناریوهای واقعی، این موضوع برای سرویسهای اجرای کد، ابزارهای اتوماسیون، سامانههای پلاگین و هر برنامهای که ورودی اجرایی از کاربر میگیرد اهمیت ویژه دارد.
GitLab Threat Research در گزارش رسمی خود توضیح میدهد که مسیر حمله با پیکربندی مستندشده vm2 قابل فعالشدن است. بنابراین صرف استفاده «طبق مستندات» بهتنهایی تضمین امنیت نیست و باید کنترلهای دفاعی بیرون از خود Sandbox هم وجود داشته باشد.
RCE و Sandbox Escape چه تفاوتی دارند؟
Sandbox Escape یعنی مهاجم از مرز محیط محدودشده عبور میکند. RCE یا Remote Code Execution نتیجهای است که در برخی سناریوها پس از شکستن این مرز رخ میدهد و به اجرای کد یا فرمان روی سیستم هدف میانجامد. ترکیب این دو، مخصوصاً روی سروری که پردازش Node.js دسترسی گسترده دارد، میتواند از یک باگ در سطح اپلیکیشن به رخدادی در سطح سیستمعامل تبدیل شود.
چه سرویسهایی باید سریعتر بررسی شوند؟
- پلتفرمهایی که JavaScript کاربران را اجرا میکنند.
- سرویسهای Code Runner، اتوماسیون و Workflow که از vm2 یا wrapperهای مبتنی بر آن استفاده میکنند.
- برنامههایی که پلاگین یا اسکریپت شخص ثالث را داخل Node.js اجرا میکنند.
- سرویسهای چندمستاجری که چند کاربر روی یک میزبان یا Runtime مشترک دارند.
- اپلیکیشنهایی که پردازش Node.js آنها با سطح دسترسی بالا اجرا میشود.
چطور بررسی کنیم پروژه از vm2 استفاده میکند؟
ابتدا وابستگی مستقیم و غیرمستقیم را بررسی کنید. در پروژههای npm میتوانید از دستورهای زیر شروع کنید:
npm ls vm2
npm explain vm2اگر از lockfile و CI استفاده میکنید، فقط package.json را نبینید؛ نسخه واقعاً نصبشده در محیط Production و زنجیره وابستگی را هم کنترل کنید. برای آشنایی با محیط اجرای Node.js روی سرور، مقاله آموزش نصب Node.js و npm در CentOS در آکادمی وانسرور میتواند مرجع تکمیلی باشد.
اقدامات فوری برای کاهش ریسک
۱. اجرای کد غیرقابلاعتماد را موقتاً محدود کنید
اگر vm2 در مسیر اجرای ورودی کاربر قرار دارد، تا روشنشدن وضعیت نسخه و اصلاحات، این قابلیت را غیرفعال یا به محیط جداگانه منتقل کنید. در رخدادهای Sandbox Escape، کاهش سطح مواجهه از هر تنظیم ریز داخل برنامه مهمتر است.
۲. نسخه و Advisoryهای رسمی را تطبیق دهید
نسخه نصبشده، lockfile و Advisory رسمی GitLab را با هم بررسی کنید. بهروزرسانی صرف package.json بدون Deploy مجدد یا بدون تغییر نسخه قفلشده کافی نیست.
۳. اصل Least Privilege را در سطح سیستمعامل اجرا کنید
پردازش Node.js نباید با root اجرا شود. دسترسی فایل، متغیرهای محیطی، Secretها، شبکه خروجی و مسیرهای Mountشده را محدود کنید. اگر Sandbox شکست، این کنترلها شعاع آسیب را کم میکنند.
۴. ایزولیشن را از Process جدا کنید
برای اجرای کد واقعاً غیرقابلاعتماد، اتکا به یک Sandbox درون همان Process ریسک بالایی دارد. بسته به مدل تهدید، جداسازی در Container، VM یا Runtime ایزوله با محدودیت CPU، RAM، filesystem و network میتواند مرز دفاعی قویتری ایجاد کند.
۵. لاگها و نشانههای سوءاستفاده را بررسی کنید
فرآیندهای فرزند غیرمنتظره، اجرای shell، اتصال خروجی ناشناس، خواندن Secretها، تغییر فایلهای حساس و جهش مصرف CPU/RAM را بررسی کنید. اگر شواهدی از اجرای کد ناشناس وجود دارد، موضوع را صرفاً با Update بسته نبندید و Incident Response کامل انجام دهید.
معماری امنتر برای اجرای کد ناشناس
اگر محصول شما ذاتاً باید کد کاربران را اجرا کند، بهتر است طراحی را بر پایه «فرض شکست Sandbox» انجام دهید. هر Job را با هویت کمدسترسی، فایلسیستم موقت، شبکه محدود، Secretهای حداقلی و زمان اجرای محدود اجرا کنید. برای محیطهایی که نیاز به کنترل کامل سیستمعامل و ایزولیشن شبکه دارند، استفاده از سرور مجازی با دسترسی مدیریتی کامل امکان پیادهسازی سیاستهای جداسازی و مانیتورینگ دقیقتر را فراهم میکند.
آیا فقط بهروزرسانی vm2 کافی است؟
خیر. Patch یا ارتقای وابستگی بخش ضروری پاسخ است، اما اگر معماری شما اجرای کد غیرقابلاعتماد را در همان Process و با دسترسی گسترده انجام میدهد، ریسک ساختاری باقی میماند. پس از اصلاح نسخه، سطح دسترسی Runtime، جداسازی workload، Secret management و مانیتورینگ را نیز بازبینی کنید.
جمعبندی
گزارش ۲ سپتامبر ۲۰۲۶ GitLab درباره vm2 یادآوری میکند که Sandbox نرمافزاری نباید تنها مرز امنیتی برای اجرای کد ناشناس باشد. اولویت عملی این است: وابستگی را شناسایی کنید، مسیر اجرای کد غیرقابلاعتماد را محدود کنید، نسخه امن را اعمال کنید، پردازش را با حداقل دسترسی اجرا کنید و برای workloadهای پرریسک از ایزولیشن سطح سیستم یا ماشین مجازی استفاده کنید.
منابع: GitLab Threat Research، گزارش «Critical remote code execution in vm2» (۲ سپتامبر ۲۰۲۶)؛ GitLab Advisory Database و مستندات رسمی npm/Node.js برای بررسی وابستگیها.