КРАТКО
Исследование «Extension Resurrection» («Воскрешение расширений»), проведенное компанией Bloom Security, показало, что легитимные пакеты расширений для VS Code и Open VSX могут ссылаться на расширения, которых не существует в маркетплейсе. Злоумышленники могут захватить эти пространства имен и опубликовать вредоносные расширения, которые устанавливаются автоматически через доверенные пакеты. 677 из 4 179 пакетов VS Code и 94 из 321 пакета Open VSX оказались уязвимы, а общее количество их загрузок превысило 500 000. После сообщения от Bloom компании Microsoft и Eclipse Foundation внедрили защитные механизмы.
Команды безопасности годами тщательно изучали программные зависимости, репозитории пакетов и сборочные пайплайны. Последнее исследование Bloom Security показывает, что еще одна часть цепочки поставок программного обеспечения заслуживает более пристального внимания: расширения, которые разработчики устанавливают в свои среды разработки (IDE).
В ходе исследования компании «Extension Resurrection» были изучены пакеты расширений на Visual Studio Code Marketplace и Open VSX. Специалисты Bloom выяснили, что легитимные пакеты могут содержать ссылки на расширения, которых на самом деле не существовало на маркетплейсе. Это создает для злоумышленников возможность занять такие неиспользуемые пространства имен и опубликовать под ними вредоносные расширения.
Исследование выявило 94 пакета расширений Open VSX из 321, содержащих по меньшей мере одну «теневую зависимость» (Shadow Dependency). В каталоге VS Code Marketplace компания Bloom обнаружила 677 пакетов из 4 179 с аналогичными зависимостями. Суммарное количество загрузок уязвимых пакетов превысило 500 000.
Суть проблемы — в модели доверия
Особенность этого открытия заключается в том, что для атаки не требуется убеждать разработчика установить незнакомое расширение. Разработчик уже принял решение о доверии, установив легитимный пакет расширений.
Это решение может распространяться на множество зависимостей, которые пользователь может никогда не проверять по отдельности. Исследование Bloom демонстрирует, как отсутствующее расширение внутри такой цепочки может стать лазейкой, если маркетплейс продолжает распознавать его идентификатор, одновременно позволяя кому-то другому зарегистрировать соответствующее пространство имен.
В результате возникает разрыв между тем, что разработчики считают одобренным, и тем, что их среда разработки может установить в конечном итоге.
Автоматизация усугубляет проблему
Исследование Bloom также подчеркивает роль автоматических обновлений. Пакеты расширений не фиксируют входящие в их состав расширения на определенных версиях, а значит, установленный в прошлом пакет потенциально может получить недавно опубликованную версию ранее отсутствовавшей зависимости.
Это меняет характер рисков. Организации вовсе не обязательно устанавливать вредоносное расширение сегодня, чтобы подвергнуться угрозе. Разработчик мог установить легитимный пакет несколько недель, месяцев или даже лет назад, а позже получить расширение через механизм обновления пакета.
Специалисты Bloom выяснили, что общее число загрузок уязвимых пакетов превысило 500 000, что наглядно демонстрирует потенциальный масштаб проблемы.
Технические последствия также весьма серьезны. По данным Bloom, расширения для VS Code и совместимых IDE, таких как Cursor, Kiro, Windsurf, Antigravity, VSCodium и Eclipse Theia, работают с правами хоста Node.js. Они могут читать и записывать файлы, порождать дочерние процессы и выполнять исходящие сетевые запросы.
Проблема проектирования маркетплейсов
Выводы Bloom в конечном счете указывают на уязвимости в том, как маркетплейсы работали с зависимостями и пространствами имен.
Компания выделила два основных пробела: маркетплейсы могли принимать пакеты, содержащие ссылки на несуществующие расширения, а пространства имен, на которые ссылалось существующее ПО, оставались доступными для регистрации. В совокупности эти условия позволяли злоумышленнику превратить спящую ссылку в активную зависимость.
Проблема не ограничивалась одними лишь пакетами расширений. В ходе расследования эксперты Bloom обнаружили, что с той же базовой уязвимостью могут сталкиваться и зависимости расширений Open VSX, объявленные в манифестах.
Обе площадки отреагировали на уязвимость после раскрытия информации. Компания Bloom сообщила о проблеме в Open VSX для Eclipse Foundation 5 февраля 2026 года и отметила, что команда оперативно приняла меры для защиты рискованных пространств имен и внедрения проверок на наличие несуществующих расширений и зависимостей.
17 февраля Bloom уведомила о проблеме компанию Microsoft. Изначально Microsoft присвоила уязвимости статус «умеренной» (Moderate), однако затем возобновила разбирательство после предоставления дополнительных доказательств со стороны Bloom. Впоследствии корпорация подтвердила, что средства защиты от «воскрешения расширений» внедрялись поэтапно: защита на уровне действий администратора появилась в октябре 2025 года, а защита на уровне действий пользователей была завершена в июне 2026 года.
Что результаты исследования означают для команд безопасности
Главный урок из исследования Bloom заключается не столько в конкретной уязвимости конкретного маркетплейса, сколько в том, как организации подходят к защите рабочих мест разработчиков.
Расширения для IDE часто воспринимаются как инструменты повышения продуктивности, а не как программные компоненты, требующие постоянного контроля безопасности. Тем не менее они имеют глубокий доступ к системам, на которых трудятся разработчики, а пакеты расширений могут многократно увеличивать число компонентов, попадающих в систему в результате всего одной установки.
Для команд безопасности это означает, что контроль должен распространяться на установленные расширения и пакеты, их конфигурации, поведение при автоматическом обновлении, а также на возможности отдельных расширений. Кроме того, необходимо понимать, что доверенная установка не обязательно является неизменным снимком того, что в действительности запускается на конечной точке.
Исследование Bloom наглядно показывает, как казалось бы незначительный пробел — зависимость, ссылающаяся на несуществующий компонент — может превратиться в серьезную проблему безопасности цепочки поставок в сочетании с автоматической установкой и обновлениями.
Следовательно, главный вопрос для организаций заключается не просто в том, какие расширения одобрили разработчики, а в том, какие именно расширения их среды разработки способны установить без дополнительных запросов.
Опубликовано 13 августа 2026 - 08:54 Наверх
