В библиотеке vm2 для Node.js раскрыли 12 критических уязвимостей с оценкой CVSS до 10.0. Они позволяют вредоносному JavaScript-коду выйти из «песочницы» и запустить команды на сервере, если приложение использует уязвимые версии vm2.

Риск касается разработчиков, SaaS-сервисов, внутренних корпоративных платформ и любых систем, где запускают недоверенный JavaScript: плагины, пользовательские скрипты, правила автоматизации или код из внешних источников. Исправления вошли в vm2 3.11.2.

Что такое vm2 и почему к ней столько внимания

vm2 — популярная библиотека с открытым исходным кодом для Node.js. Её используют, чтобы запускать недоверенный JavaScript в изолированной среде: код видит ограниченный набор объектов и не должен получать доступ к файловой системе, процессам и окружению сервера.

Такая «песочница» нужна там, где пользователям разрешают писать свои сценарии: например, в конструкторах ботов, системах автоматизации, онлайн-редакторах кода, платформах для тестирования и внутренних инструментах DevOps. Если изоляция ломается, граница между пользовательским кодом и сервером исчезает.

В обычной жизни это выглядит далеко от пользователя: кто-то ищет «что с дискорд сейчас», кто-то открывает discord web version и видит только веб-интерфейс. Но за такими сервисами часто стоят серверные JavaScript-компоненты, а их ошибки уже бьют по данным, токенам доступа и инфраструктуре.

Какие уязвимости нашли

Исследователи описали 12 проблем в vm2. Большинство получили оценку 9.8 по шкале CVSS, три уязвимости — максимальные 10.0. Главный сценарий один: атакующий добивается выхода из «песочницы» и переходит к удалённому выполнению кода (remote code execution — запуск команд на чужой системе через сеть).

Среди затронутых версий — ветки до 3.10.3, 3.10.4, 3.10.5, 3.11.0 и 3.11.1. Часть ошибок закрыли в 3.10.5 и 3.11.0, ещё одну — в 3.11.1, но последние две, CVE-2026-44008 и CVE-2026-44009, закрыты только в 3.11.2.

Поэтому выборочная установка промежуточного патча не спасает. Если в проекте стоит vm2 3.11.1 или ниже, безопасная цель — обновление до 3.11.2 и последующая проверка зависимостей.

Чем грозит выход из «песочницы»

После выхода из изоляции атакующий может получить доступ к тому, что недоверенный скрипт видеть не должен: переменным окружения, ключам API, токенам сессий, временным файлам, сетевым запросам и внутренним библиотекам. В худшем случае он запускает команды операционной системы от имени процесса Node.js.

На практике это может привести к краже секретов из CI/CD, подмене данных в приложении, установке вредоносных модулей или дальнейшему движению по серверной сети. Похожую логику риска мы разбирали в материале про то, как уязвимость Ollama грозит утечкой ключей API и переписок: один слабый компонент открывает доступ к данным, которые разработчики считали внутренними.

Важно и то, что vm2 часто попадает в проект не напрямую. Команда может не помнить о ней, если библиотеку подтянул другой пакет. Поэтому проверять нужно не только package.json, но и lock-файлы, контейнеры, образы сборки и старые ветки продукта.

Почему JavaScript-«песочницы» так трудно защищать

JavaScript гибок: прототипы, промисы, обработчики ошибок, свойства объектов и системные функции дают разработчикам много свободы. Та же гибкость помогает исследователям находить обходы изоляции, когда защитный слой не учитывает редкое поведение языка или новой версии Node.js.

В опубликованном списке есть ошибки, связанные с обработкой служебных свойств, функциями инспекции, исключениями, прототипами и списками разрешённых модулей. Одна из проблем позволяла загрузить встроенные модули Node.js, которые должны были быть запрещены, включая модуль для запуска дочерних процессов.

Ситуацию усиливает история vm2: незадолго до новой серии исправлений сопровождающий проекта Patrik Simek уже выпускал патч для другой критической ошибки, CVE-2026-22709, тоже связанной с выходом из «песочницы». Это не повод немедленно выбрасывать все изоляторы, но повод не считать их абсолютной границей безопасности.

Что проверить разработчикам и администраторам

Первый шаг — инвентаризация. Нужно найти vm2 во всех Node.js-проектах: основных репозиториях, микросервисах, админ-панелях, тестовых стендах, старых Docker-образах и инструментах автоматизации.

Дальше стоит обновить зависимость до 3.11.2, пересобрать lock-файлы и прогнать тесты. Если продукт запускает пользовательский код, полезно дополнительно ограничить права процесса: отдельный пользователь ОС, минимум доступа к файлам, отдельные секреты для среды выполнения, сетевые ограничения на уровне инфраструктуры.

Администраторам, которые работают с серверами из гостиниц, коворкингов и кафе, стоит защищать не только код, но и канал связи: сервис безопасного интернет-соединения помогает защитить интернет-соединение и приватность данных при работе в публичных сетях. Это не заменяет патчи, но снижает риск перехвата учётных данных во время срочных работ.

Обновления платформы тоже нельзя откладывать бесконечно. Мы уже писали, почему даже обычные изменения в ОС требуют внимания к безопасности: см. разбор про то, что важно учесть, когда Windows 11 получила новые бета-сборки.

Практический вывод: чек-лист на ближайший день

  • Найдите vm2 в package.json, package-lock.json, yarn.lock, pnpm-lock.yaml и Docker-образах.
  • Проверьте, нет ли версий vm2 3.11.1 и ниже. Если есть — обновите до 3.11.2.
  • Пересоберите зависимости и заново выпустите контейнеры, где используется Node.js.
  • Проверьте сервисы, которые запускают пользовательский JavaScript: плагины, правила автоматизации, онлайн-редакторы, тестовые песочницы.
  • Ограничьте права процесса Node.js: минимум доступа к файлам, секретам и внутренней сети.
  • Уберите долгоживущие токены из окружения там, где выполняется недоверенный код.
  • Включите журналирование попыток запуска системных команд и доступа к чувствительным файлам.
  • Если обновление нельзя поставить сразу, временно отключите запуск пользовательских скриптов или вынесите его в максимально изолированную среду.
Поделиться: