Сразу 36 пакетов в npm оказались заражены новым инфостилером IronWorm, и это не очередная история про «подсунули вредоносный скрипт в зависимость». Эта атака на npm бьет туда, где у команд сейчас самые чувствительные точки: переменные окружения в CI, токены публикации, ключи к облакам и автоматизированные пайплайны, от которых зависит выпуск релизов.
По данным BleepingComputer, IronWorm охотится за 86 переменными окружения и 20 файлами с учетными данными. В списке целей — секреты OpenAI, AWS, Anthropic и npm, конфиги Vault, SSH-ключи и файлы криптокошелька Exodus. Исследователи JFrog описывают малварь как Rust-имплант, который маскируется с помощью eBPF-руткита в ядре и общается с оператором через Tor. Иными словами, это уже не кустарный пакет с обфусцированным JavaScript, а аккуратно собранный инструмент под цепочку разработки.
Главная неприятность в том, что IronWorm умеет размножаться сам. Если вредонос попадает в окружение разработчика или в CI, он пытается использовать украденные учетные данные для публикации новых версий пакетов от имени жертвы. Под ударом оказываются и секреты, связанные с Trusted Publishing в npm. Дальше схема проста и неприятна: зараженный пакет тянет следующую волну заражений, а скомпрометированный аккаунт разработчика превращается в точку распространения по всей экосистеме. Для JavaScript-мира это особенно болезненно, потому что здесь доверие к цепочке зависимостей давно стало производственным риском, а не только головной болью AppSec-команды.
Судя по данным JFrog, отправной точкой стал скомпрометированный аккаунт asteroiddao, через который были опубликованы версии пакетов с Rust ELF-бинарником. Он запускался через preinstall и, помимо кражи данных, проталкивал вредоносные коммиты в репозитории. Автор коммитов обозначен как «claude», а метки времени у некоторых изменений уводят расследователей на несколько лет назад — местами до 13 лет, хотя сами коммиты были отправлены в последние дни. Такой прием выглядит как попытка затруднить разбор инцидента и размазать хронологию, чтобы защитники дольше спорили о происхождении артефактов, чем изолировали зараженные окружения.
Отдельно исследователи описали интересный механизм вывода украденных секретов через GitHub Actions. Малварь может собрать данные в одно значение, записать их в файл с безобидным названием — так, будто это результат линтера или форматтера, — а затем загрузить этот файл как build artifact. Для атакующего это почти подарок: внешний C2-сервер в такой схеме вообще не обязателен, достаточно доступа к артефактам сборки. Впрочем, JFrog уточняет, что именно в разобранной атаке на npm этот способ доставки не использовался. Но сам факт, что такой путь предусмотрен, хорошо показывает, куда сместился центр тяжести supply-chain атак: теперь атакуют не только пакетный реестр, но и окружающую его DevOps-инфраструктуру.
Есть и деталь в духе плохой оперативной безопасности самих злоумышленников. JFrog обнаружила, что оператор захардкодил seed-фразу от собственного криптокошелька. Исследователи предполагают, что это было сделано лишь затем, чтобы малварь не украла ее на этапе тестирования. Деталь почти комичная, но вывод из нее серьезный: IronWorm, похоже, не был случайной сборкой из готовых фрагментов. Исследователи прямо пишут, что это «кастомный, тщательно собранный имплант» с собственной инфраструктурой. При этом четкой связи с недавней кампанией Shai Hulud они не нашли, хотя заметили одинаковые имена коммитов в обеих цепочках атак. Отсюда осторожная гипотеза: перед нами может быть развитие подходов, которые уже обкатали в предыдущих инцидентах с npm.
Контекст тут важнее самого названия IronWorm. За последние месяцы npm все чаще фигурирует в историях не просто о зараженных пакетах, а о самораспространяющихся цепочках, где компрометация одной машины разработчика быстро превращается в проблему для десятков команд. В материале BleepingComputer рядом упоминаются и свежие волны Shai Hulud, и более ранние случаи с кражей учетных данных через популярные npm-пакеты. Это уже не серия независимых инцидентов, а устойчивая модель атаки: сначала похищаются токены и секреты, затем заражается CI или аккаунт публикации, после чего атакующий использует доверие к уже существующим пакетам и рабочим процессам.
Хорошая новость в том, что этот конкретный эпизод, похоже, заметили достаточно рано. В Ox Security заявили, что распространение удалось остановить до того, как вредонос добрался до более популярных пакетов в npm. Компания опубликовала список затронутых имен и версий и советует разработчикам перейти на исправленные релизы, сменить ключи и включить двухфакторную аутентификацию для всех аккаунтов. Параллельно Endor Labs и StepSecurity обнаружили очень похожую, но все же отдельную кампанию с JavaScript-малварью binding.gyp, где использовались отравление реестра и заражение GitHub Actions в те же сроки. Для бизнеса это означает простую вещь: одной проверки package-lock и редкого аудита зависимостей уже недостаточно. Защищать приходится и registry, и CI, и правила Trusted Publishing, и хранение секретов, и права сервисных аккаунтов.
Для русскоязычных команд разработки атака на npm в 2026 году выглядит уже не как локальная проблема фронтенд-экосистемы, а как проверка зрелости всей инженерной дисциплины. Если токен публикации лежит в переменной окружения без жесткой ротации, если GitHub Actions артефакты видят лишние люди, если 2FA включена не у всех, то вопрос уже не в JavaScript и не в конкретном пакете. Вопрос в том, насколько легко злоумышленник может превратить ваш CI в собственный канал дистрибуции. И чем чаще supply-chain атаки начинают жить сразу в npm, GitHub Actions и облачных секретах, тем очевиднее становится новый стандарт: доверять нужно не пакету, а всей цепочке сборки целиком.