Исследование Bloom Security о восстановлении расширений выявляет слепую зону в безопасности разработчиков

      TL;DR Исследование Bloom Security «Воскрешение расширений» показало, что легитимные пакеты расширений VS Code и Open VSX могут ссылаться на расширения, которых не существует на рынке. Злоумышленники могут заявить о своих правах на эти пространства имен и публиковать вредоносные расширения, которые устанавливаются автоматически через доверенные пакеты. 677 из 4179 пакетов VS Code и 94 из 321 пакета Open VSX оказались уязвимыми, с более чем 500,000 загрузок в сумме. После раскрытия информации Bloom как Microsoft, так и Eclipse Foundation внедрили меры защиты.

      Команды безопасности потратили годы на изучение зависимостей программного обеспечения, репозиториев пакетов и конвейеров сборки. Последние исследования Bloom Security предполагают, что еще одна часть цепочки поставок программного обеспечения заслуживает более пристального внимания: расширения, которые разработчики устанавливают в своих IDE.

      Исследование компании «Воскрешение расширений» изучило пакеты расширений на рынке Visual Studio Code и Open VSX. Bloom обнаружил, что легитимные пакеты могут содержать ссылки на расширения, которые на самом деле не существуют на рынке, создавая возможность для злоумышленников заявить о своих правах на эти неиспользуемые пространства имен и публиковать вредоносные расширения под ними.

      Исследование выявило 94 из 321 пакета расширений Open VSX с как минимум одной «Теневой зависимостью». На рынке VS Code Bloom нашел 677 из 4179 пакетов с как минимум одной такой зависимостью. В уязвимых пакетах количество загрузок превысило 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 года и заявил, что команда быстро приняла меры для защиты уязвимых пространств имен и внедрения проверок на несуществующие расширения и зависимости.

      Bloom сообщил о проблеме Microsoft 17 февраля. Microsoft первоначально оценил ее как Умеренную, прежде чем снова открыть дело после того, как Bloom предоставил дополнительные доказательства. Впоследствии Microsoft подтвердила, что меры защиты от воскрешения расширений были внедрены поэтапно, с мерами защиты, требующими действий администратора, начиная с октября 2025 года, и мерами защиты, требующими действий пользователя, завершенными в июне 2026 года.

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

      Широкий урок из исследования Bloom заключается не столько в одной конкретной уязвимости рынка, сколько в том, как организации думают о конечных точках разработчиков.

      Расширения IDE часто рассматриваются как инструменты повышения производительности, а не как программные компоненты, требующие постоянного контроля безопасности. Тем не менее, они могут иметь глубокий доступ к системам, на которых работают разработчики, и пакеты расширений могут умножать количество компонентов, вводимых через одну установку.

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

      Исследование Bloom демонстрирует, как, казалось бы, незначительный пробел, зависимость, указывающая на что-то, чего не существует, может стать значительной проблемой безопасности цепочки поставок, когда она комбинируется с автоматической установкой и обновлениями.

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