Open VSX удалил 77 расширений-двойников после утечки данных разработчиков
Маркетплейс Open VSX удалил 77 вредоносных расширений, которые выдавали себя за настоящие инструменты разработчиков и передавали сведения об устройствах и рабочих средах. По данным Manifold Security, пакеты появились в репозитории с 26 июля по 1 августа 2026 года и были удалены к 3 августа. Из них 58 собирали главным образом имя компьютера, а 19 проводили расширенную разведку.
Как маскировались подделки
Расширения повторяли названия, пространства имён и описания легитимных публикаций Open VSX, однако загружались из несвязанных учётных записей и обычно получали низкую версию, например 0.0.1. Злоумышленники заменяли содержимое файла extension.js, называя сбор информации «анонимными метриками использования».
Заявленных в карточках функций пакеты не предоставляли. После запуска они показывали элемент в строке состояния и сообщение об активности, а затем отправляли данные на домен mangorbit[.]com. Он был зарегистрирован 15 июля 2026 года — за 11 дней до публикации первых расширений.
Эта кампания продолжает модель, в которой заимствованное доверие стало главной тактикой атак помогает вредоносному коду пройти первичную проверку пользователя, но в Open VSX доверие заимствовали через копирование карточек известных инструментов.
Какие сведения уходили с компьютеров
Облегчённые варианты передавали имя устройства, а иногда также папку проекта или версию редактора. Девятнадцать разведывательных расширений собирали имя пользователя ОС, название и версию редактора, идентификатор машины, платформу, архитектуру, локаль, часовой пояс, имя каталога проекта и полный путь к нему.
Кроме того, вредоносный код просматривал каталог .git, извлекая адреса удалённых репозиториев, организации, домен электронной почты разработчика, текущую ветку и SHA-хеш HEAD. Он перечислял до 60 установленных расширений, определял прокси и считывал маркеры CI, включая переменные GitHub, GitLab, Azure DevOps, Buildkite, CircleCI, Codespaces и Gitpod.
Повторные попытки и резервный канал
Разведывательный вариант проверял настройку отказа от телеметрии и выяснял, указано ли его расширение в файлах devcontainer.json или .vscode/extensions.json проекта. Это позволяло отличить установку, вызванную конфигурацией репозитория, от ручного выбора разработчика.
При недоступности основного домена код мог получить запасной адрес через DNS TXT. Повторные попытки выполнялись примерно через 15 и 50 минут, затем через три с половиной часа и далее каждые семь-восемь часов. После перезапуска редактора цикл возобновлялся и мог продолжаться до семи дней.
Что проверить компаниям
Командам стоит сопоставить установленные расширения со списком кампании, проверить издателя и историю версий, а также изучить исходящие соединения рабочих станций к mangorbit[.]com. Отдельного внимания требуют проекты, где расширения подключаются автоматически через конфигурацию репозитория.
Практический вывод для бизнеса состоит в том, что знакомого имени и описания в каталоге недостаточно для доверия. Контроль расширений должен учитывать аккаунт издателя, реальную функциональность, сетевое поведение и доступ к Git- и CI-данным, поскольку именно эти сведения позволяют раскрыть структуру разработки и используемую инфраструктуру.