Вредоносная версия npm-пакета Jscrambler прожила в реестре около двух часов, но этого хватило для 1479 загрузок. Для разработчиков это не просто еще одна атака на npm: зараженный пакет запускал стилер на этапе установки и мог унести исходники, токены CI/CD, облачные ключи и даже конфигурации AI-инструментов, которые все чаще лежат прямо в рабочем окружении.
О компрометации сообщает BleepingComputer со ссылкой на саму Jscrambler. Компания обнаружила, что злоумышленник опубликовал несанкционированные версии пакета jscrambler, используемого вместе с продуктом Code Integrity. Под заражение попали релизы 8.14, 8.16, 8.17 и 8.20. Вредоносный код запускался через хук preinstall, то есть еще до того, как разработчик успевал разобраться, что именно к нему приехало вместе с зависимостью.
Jscrambler уточняет, что инцидент затронул только этот npm-пакет и не распространился на другие продукты компании, включая Webpage Integrity. После обнаружения проблемы разработчик депрецировал зараженные версии и выпустил безопасную 8.22. Но тайминг здесь не слишком утешительный: за те самые два часа вредоносный пакет успел разойтись почти полторы тысячи раз. Для пакета с примерно 17 тысячами еженедельных загрузок это не те цифры, которые можно списать на лабораторный инцидент без последствий.
Отдельно неприятно то, что скомпрометированный пакет был зависимостью еще для четырех пакетов Jscrambler. Их тоже пришлось депрецировать и заменить новыми версиями. Это классическая проблема supply chain в экосистеме JavaScript: даже если команда не ставила проблемный пакет напрямую, он мог приехать транзитивно. А дальше все решает автоматика: CI подхватывает свежую версию, разработчик делает обычный npm install, и заражение оказывается не в теории, а на рабочей машине или в сборочной среде.
Анализ вредоносной версии выполнила компания Socket, которая и заметила компрометацию. По ее данным, внутри пакета находился инфостилер с довольно широким аппетитом. Он был нацелен на исходный код и файлы проектов, учетные данные разработчиков, Git- и SSH-конфигурации, переменные окружения, токены CI/CD, облачные креды для AWS, Azure, GCP и Kubernetes, а также данные из секрет-менеджеров. Отдельный штрих эпохи: в списке интересов вредоноса оказались конфигурации AI-кодинг-инструментов и MCP, включая Claude, Cursor, Windsurf, VS Code и Zed. То есть атака на npm бьет уже не только по классическим dev-секретам, но и по новому рабочему слою, который многие команды еще даже не внесли в модели угроз.
На этом список не заканчивался. Исследователи указывают, что малварь собирала данные браузеров, в том числе cookie и сохраненные логины, а также артефакты из Slack, Discord и Telegram. В описании фигурируют и криптокошельки с seed-фразами: MetaMask, Phantom, Coinbase, Exodus, Trust Wallet. Иными словами, речь не о грубом скрипте, который вытаскивает пару env-переменных, а о вполне взрослом наборе для кражи всего, до чего можно дотянуться с машины разработчика.
Технически злоумышленник постарался усложнить разбор. По данным Socket, в пакете использовалась сильная построчная обфускация с алгоритмом ChaCha20-Poly1305, из-за чего реверс занимал больше времени. Для защитников это плохая новость, но не сенсация: атакующие давно поняли, что главный шанс выжить в npm-экосистеме даже не недели, а часы. Поэтому задача малвари не в изяществе, а в том, чтобы успеть отработать до удаления из реестра и до первых алертов от исследователей.
Причиной компрометации Jscrambler назвала захват учетных данных для публикации в npm. Компания сообщила, что эти креды уже отозваны, а в пайплайн публикации добавлены дополнительные меры защиты. Детали новых контролей она не раскрывает, но сам сценарий до боли знаком: если доступ к публикации пакета можно украсть одной учеткой, значит, в цепочке поставки все еще слишком много доверия к одному секрету. На фоне свежих атак на npm это уже не эксцесс, а устойчивый паттерн.
Для русскоязычных команд здесь несколько практических выводов, и все они неприятные. Во-первых, проверять нужно не только прямые зависимости, но и транзитивные, особенно если пакет участвует в сборке или имеет install-хуки. Во-вторых, компрометация девелоперской машины теперь автоматически означает риск для Git, облака, CI, корпоративных мессенджеров и внутренних AI-настроек. В-третьих, реакция формата «обновим пакет и поедем дальше» в таком кейсе слабовата. Jscrambler прямо рекомендует считать окружения скомпрометированными, ротировать все секреты и подниматься из заведомо чистых бэкапов. Это уже уровень incident response, а не рутинного dependency update.
Бизнес-смысл истории тоже довольно прямой. Компании любят говорить про безопасную разработку, но часто продолжают жить в модели, где npm install считается технической мелочью, а не точкой входа. Между тем supply-chain-атаки бьют не по perimeter, а по самому контуру создания продукта. Если у злоумышленника появляются исходники, токены пайплайнов и облачные креды, дальше вопрос не в том, был ли заражен один пакет, а в том, насколько глубоко атакующий успел пройти по цепочке доверия внутри компании.
Атака на npm в случае Jscrambler особенно иронична еще и потому, что пострадал поставщик инструмента для защиты JavaScript-кода от подмены и реверса. Но в этом и главный урок: в 2026 году атакуют уже не только популярные библиотеки с миллионами загрузок, а любую точку, через которую можно добраться до среды разработчика. Следующий фронт supply chain, похоже, будет крутиться не только вокруг пакетов и токенов, но и вокруг тех ассистентов, IDE-плагинов и MCP-конфигураций, которые команды успели встроить в ежедневную разработку быстрее, чем в свою безопасность.