Уязвимость в библиотеке vm2 позволяет выйти из изолированной среды и выполнить произвольные команды

Библиотека vm2 расширяет возможности платформы Node.js: она позволяет запускать чужой код в изолированной среде, то есть в песочнице (ограниченном окружении без доступа к основной системе). На такой схеме держатся сервисы, исполняющие скрипты пользователей. Ошибка в разграничении доступа ломает саму защиту. Злоумышленник может выйти за пределы песочницы и выполнить на сервере произвольные команды. Исправление уже опубликовано.

Детали уязвимости

Уязвимость описана в Банке данных угроз безопасности информации (BDU) под номером BDU:2026-15021, ей присвоен идентификатор CVE-2026-92957. Производитель подтвердил проблему. Класс ошибки - уязвимость архитектуры; формально речь идёт о небезопасном управлении привилегиями (CWE-269) и неправильном контроле доступа (CWE-284). Говоря проще, библиотека неверно определяет, какие операции исполняемый код вправе выполнять. В итоге код, который обязан оставаться внутри ограниченного окружения, получает доступ к системным возможностям.

Оценка опасности - критический уровень. По шкале CVSS 3.1 базовая оценка составляет 9,9, по CVSS 4.0 - 9,4. В более старой методике CVSS 2.0 балл равен 9, и там уровень обозначен как высокий. Все три значения сходятся в главном: уязвимость относится к наиболее серьёзным.

Из вектора эксплуатации следует, что атака возможна удалённо, по сети. При этом нарушителю достаточно доступа к сервису с минимальными правами. Физический доступ к оборудованию не нужен, участие пользователя также не требуется. Проверка подлинности не обходится напрямую: скорее, уже имеющийся пользователь получает больше возможностей, чем ему разрешено. В бюллетене способ эксплуатации обозначен как нарушение авторизации. Отдельно отмечено, что готовый эксплойт находится в открытом доступе. Это заметно снижает порог входа, поскольку разбираться в устройстве библиотеки атакующему не придётся.

Проблема затрагивает версии vm2 вплоть до 3.11.7. Библиотека распространяется через пакетный менеджер npm (инструмент управления библиотеками для Node.js), поэтому она часто попадает в проекты косвенно, вместе с другими зависимостями. Разработчик может даже не знать, что нужный ему компонент тянет за собой уязвимый пакет.

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

Отдельного внимания заслуживает история самой библиотеки. Нынешняя уязвимость - не первая проблема обхода изоляции в vm2. Похожие ошибки находили и раньше, причём несколько раз за короткий период. Каждый раз выпускались исправления, а сообщество обсуждало, насколько надёжна изоляция, построенная средствами одного языка программирования. Практика показывает, что такие механизмы регулярно дают сбои. Причина в том, что среда исполнения и защита работают внутри одного процесса и одной среды исполнения. Любая неучтённая деталь в правилах доступа открывает обходной путь.

Что важно для администраторов и разработчиков. Производитель выпустил обновление, устраняющее уязвимость. Обновить нужно как прямые, так и вложенные зависимости: недостаточно поправить только верхний уровень дерева пакетов. Полезно проверить, какие именно сервисы запускают пользовательский код и какие версии библиотеки они используют. Если обновление по каким-то причинам откладывается, стоит ограничить права процессов, исполняющих чужой код, и вынести их в отдельные контейнеры или виртуальные машины. Дополнительно имеет смысл включить журналирование запускаемых команд: аномальная активность внутри изолированной среды часто заметна именно на этом уровне.

Уязвимость архитектурного класса сложнее закрывать точечными правками. Изоляция на уровне языка программирования не даёт гарантий сама по себе, поэтому её обычно сочетают с системными ограничениями: разделением процессов, урезанными правами, сетевыми запретами. Пользователям vm2 рекомендуется установить исправление в кратчайшие сроки и пересмотреть архитектуру сервисов, где исполняется недоверенный код. Разработчики, выбирающие инструмент для запуска чужого кода, всё чаще смотрят в сторону отдельных процессов и контейнеров - там граница между гостем и системой проходит на уровне операционной системы, а не внутри одной библиотеки.

Детали уязвимости

Ссылки