Встроенные модули Node.js обходят изоляцию vm2 и открывают выполнение произвольного кода

Банк данных угроз безопасности информации (BDU) добавил сведения о трёх уязвимостях в библиотеке vm2. Она распространяется через пакетный менеджер NPM и служит для запуска чужого кода внутри изолированной среды, или песочницы. Такая песочница нужна там, где программа исполняет код, которому нельзя доверять. Все три уязвимости получили подтверждение производителя, а оценки по шкале CVSS доходят до 10 из 10. Готовые эксплойты, то есть код для использования уязвимости, лежат в открытом доступе. Атака ведётся удалённо, а в двух случаях злоумышленнику не нужны ни учётные данные, ни действия пользователя.

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

Первая уязвимость затрагивает компонент node:sqlite. Речь идёт о версиях от 3.11.3 до 3.11.6 включительно. Причина - нарушение механизма защиты данных: песочница не удерживает границу между исполняемым кодом и системой. Злоумышленник, действующий удалённо, получает возможность выполнить произвольный код на узле. По версии CVSS 3.1 оценка составляет 9,9, для эксплуатации нужны низкие привилегии. Идентификаторы уязвимости - BDU:2026-14939 и CVE-2026-92938.

Вторая уязвимость связана с конструктором new VM(). Она охватывает более широкий диапазон версий: от 3.10.1 до 3.11.7. Здесь оценки совпадают по всем трём редакциям шкалы и равны 10. Атака не требует ни привилегий, ни участия пользователя. Отдельно отмечено изменение области действия: это означает, что последствия выходят за границы песочницы и затрагивают процессы за её пределами. Под угрозой оказываются конфиденциальность, целостность и доступность данных. Описанные способы эксплуатации включают несанкционированный сбор информации и манипулирование ресурсами. Уязвимость получила идентификаторы BDU:2026-15022 и CVE-2026-92956.

Третья уязвимость затрагивает модули os и dns. Она присутствует в версиях до 3.11.6. Здесь речь идёт об ошибках обработки информации, раскрытии данных, неправильной авторизации и некорректной выдаче разрешений на критичные ресурсы. Оценка по CVSS 3.1 и CVSS 4.0 составляет 10, по более старой редакции 2.0 - 9,7. Последствия для доступности выражены слабее, чем для конфиденциальности и целостности. Уязвимость выявили 14 августа 2026 года, ей присвоены идентификаторы BDU:2026-15024 и CVE-2026-92960.

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

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

Разработчики уже закрыли все три уязвимости. Обновиться нужно до версии новее 3.11.7; в одной из ветвей последней уязвимой остаётся 3.11.7, поэтому ориентироваться стоит на актуальный выпуск, а не на минимальный шаг вперёд. Рекомендации производителя опубликованы в трёх бюллетенях. Тем, кто не может обновить библиотеку сразу, стоит ограничить процесс на уровне операционной системы: запускать его в контейнере с минимальными правами, закрыть доступ к файловой системе и сети, а переменные окружения с секретами не передавать внутрь. Полезно также ограничить память и время работы процесса, чтобы затруднить манипулирование ресурсами.

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

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

Ссылки