Два расширения Solidity Pro для VS Code, замеченные исследователями, использовались для кражи криптокошельков, API-ключей и учетных данных разработчиков. Для русскоязычной IT-аудитории здесь важен не только сам инцидент, но и его мишень: вредоносные расширения VS Code снова маскируются под привычные инструменты для Web3-разработки и заходят в инфраструктуру через то, что многие ставят без долгой проверки.
О находке сообщает The Hacker News со ссылкой на Yeeth Security. Речь идет о расширениях helper-beeps.solidity-pro и web3devtoolsx.solidity-pro. Из каталога Open VSX они уже исчезли, но GitHub-репозиторий, связанный с web3devtoolsx/solidity-pro, на момент публикации материала оставался доступен. Уже этого достаточно, чтобы история не выглядела как разовая ошибка модерации: вредоносный след не оборвался вместе с удалением из маркетплейса.
По данным исследователей, ранние версии расширений, от 1.0.0 до ветки 2.4.x, работали как загрузчик. Они связывались с endpoint'ами на Cloudflare Workers, получали зашифрованный Python-пейлоад и запускали его локально. Начиная с версии 3.0.0 схема стала заметно агрессивнее: вместо подгрузки внешнего кода расширение превратилось в полноценный стилер. Он собирал профили браузеров, кошельки, токены систем контроля версий, API-ключи, SSH-ключи и токены Telegram-ботов, а затем выгружал добычу через Telegram-бота. Для атакующих это практичный канал эксфильтрации: дешевый, привычный и не слишком экзотичный для массовых защитных правил.
Список интересов у стилера показательный. Среди целевых данных названы токены GitHub с префиксами ghp_ и github_pat_, токены GitLab glpat-, AWS-ключи и сессионные токены, Cloudflare-токены cfat_, ключи OpenAI форматов sk-, sk-proj- и sk-ant-, токены Telegram-ботов, seed-фразы и mnemonic-данные, а также хранилища MetaMask, Phantom, Rabby, Coinbase, Trust и Keplr. Дополнительно вредонос собирал Bitcoin WIF и xprv, приватные SSH-ключи, URL-учетки и даже MFA-токены из 1Password. Если перевести это с языка индикаторов компрометации на язык бизнеса, получается неприятная картина: под удар попадают не только личные криптоактивы разработчика, но и доступы к облакам, CI/CD, репозиториям, DNS, AI-сервисам и внутренним ботам. Один «полезный» плагин в редакторе кода может стать точкой входа сразу в несколько контуров.
Отдельно исследователи описывают технику обхода проверок. Здесь нет примитивного «скачал и сразу запустил вредонос». Авторы расширений использовали сильную обфускацию, промежуточные чистые версии для наращивания доверия и отложенную активацию, из-за которой вредоносный код запускался через часы или даже дни после установки. Для автоматических сканеров это плохая новость: если проверка смотрит пакет несколько минут, а потом идет дальше, она просто не застает полезную нагрузку в действии. Для разработчика новость еще хуже: он успевает привыкнуть к расширению, увидеть, что оно вроде бы работает, и перестать относиться к нему как к риску. В этом смысле вредоносные расширения VS Code становятся не просто каналом доставки, а довольно зрелой supply chain-атакой на повседневные инструменты инженера.
Это не первый эпизод такого рода и не узкая проблема только для Solidity-разработчиков. Yeeth Security связывает активность с тем же общим сценарием, который использовал кластер WhiteCobra: в сентябре 2025 года он распространял Lumma Stealer через вредоносные расширения VS Code. В июне 2026-го те же исследователи уже находили фальшивое Solidity-расширение ethdevtools.solidity-language-support. Там работал другой прием: delayed-activation clipboard stealer перехватывал содержимое буфера обмена и подменял криптоадреса, seed-фразы и Ethereum-ключи. Причем делалось это через штатный API vscode.env.clipboard.writeText без экзотических импортов, без сетевой активности на старте и без записи файлов. Иными словами, рынок расширений для редакторов окончательно перестал быть «второстепенной» зоной риска: атакующие уже понимают внутреннюю механику платформы и умеют играть против типовых правил детекта.
Фон тоже тревожный. Одновременно исследователи описали еще несколько кампаний: npm-пакет ascii-fetcher с вредоносной зависимостью @jaymara/jsononifier, набор из десяти VS Code-расширений с BAT-, JavaScript- и HTA-дропперами, расширение DigitalBarberTrim.html-entity-codec, которое в отдельных версиях сбрасывало удаленный VSIX после распознавания форков VS Code вроде Cursor, Windsurf, Codium и Positron, а также Zlmiles.zlmiles-liquid, загружавшее MSI-инсталлятор с домена Replit. Это важный сдвиг: злоумышленники атакуют уже не только официальный VS Code, но и весь окружающий слой инструментов разработчика. Для команд, где рядом живут Visual Studio Code, AI-IDE, open-source forks и десятки npm-зависимостей, граница между «редактором», «плагином» и «локальной supply chain» становится все более условной.
Практический вывод для разработчиков, тимлидов и безопасников довольно приземленный. Если в компании кто-то работает с Solidity, кошельками, Web3 SDK или просто держит в браузере и редакторе чувствительные токены, аудит расширений IDE пора поднимать до уровня обычной гигиены, а не факультативной паранойи. Минимум, который напрашивается из этого кейса: удаление подозрительных расширений, проверка графа зависимостей, ревизия утекших ключей и токенов, ротация SSH и облачных доступов, а также алерты на запуск cscript, mshta, cmd, curl и powershell там, где подобная активность не считается нормой. Для HR и IT-руководителей вывод тоже неприятный: риск уже давно не ограничен серверным периметром, он сидит прямо в developer experience, которое принято ускорять любой ценой.
Главный вопрос теперь не в том, удалят ли еще одну вредоносную публикацию из каталога, а в том, насколько сами площадки и команды готовы к модели, где вредоносные расширения VS Code неделями изображают полезный инструмент и лишь потом вскрывают доступы ко всему стеку. Чем больше в разработке ключей, агентов, кошельков и локальных интеграций, тем дороже обходится привычка доверять расширению только потому, что оно называется похоже на нужный пакет. Подробнее об исходном кейсе можно посмотреть в материале .