1 июня 2026 года исследователи сообщили о компрометации 32 npm-пакетов из пространства @redhat-cloud-services, связанных с фронтенд-инструментами Red Hat Cloud Services. В опубликованных версиях обнаружили вредоносный код Miasma, который запускался при установке пакета и пытался собрать секреты разработчиков, токены CI/CD и облачные ключи.
Вредоносные версии затронули 32 пакета Red Hat Cloud Services
Исследователи Aikido, Socket, Wiz, OX Security и другие команды по безопасности сообщили о новой атаке на цепочку поставки в экосистеме npm. Под удар попали пакеты из пространства имён @redhat-cloud-services, которое используется для компонентов и клиентских библиотек, связанных с Red Hat Cloud Services.
По данным Aikido, компрометация затронула 96 версий в 32 пакетах. Совокупно эти пакеты набирали около 117 тысяч загрузок в неделю. BleepingComputer также приводит заявление Red Hat: компания заявила, что начала расследование, удалила затронутые пакеты из npm registry и пока не выявила воздействия на клиентские и партнёрские окружения, а также на производственные системы Red Hat.
Важно понимать масштаб новости. npm — это один из главных реестров пакетов для JavaScript и Node.js. Разработчики подключают зависимости через npm install, а затем эти библиотеки становятся частью локальной разработки, сборки, тестирования и CI/CD-конвейеров. Если злоумышленник получает возможность опубликовать заражённую версию популярного пакета, вредоносный код может попасть не в один проект, а сразу во множество рабочих станций и сборочных сред.
В этой атаке вредоносный код был найден в пакетах, опубликованных под официальным пространством Red Hat Cloud Services. Для обычного разработчика это особенно опасный сценарий: имя пакета выглядит доверенным, установка проходит привычной командой, а вредоносная логика запускается до того, как человек успевает использовать библиотеку в коде.
Miasma запускался во время установки пакета
Главная техническая деталь инцидента связана с npm lifecycle scripts — служебными скриптами, которые npm может запускать на разных этапах установки пакета. В скомпрометированных версиях использовался preinstall-скрипт:
{
"scripts": {
"preinstall": "node index.js"
}
}Такой скрипт выполняется автоматически во время установки зависимости. Разработчику не нужно импортировать пакет, запускать приложение или вызывать функцию из библиотеки. Достаточно установить зависимость, и вредоносный файл уже получает шанс выполниться в окружении пользователя или CI/CD-системы.
Socket описывает вредоносный загрузчик как многоступенчатый и обфусцированный. Обфускация — это намеренное запутывание кода, чтобы усложнить анализ. В отчётах говорится о скрытом JavaScript-загрузчике, зашифрованных фрагментах полезной нагрузки и выполнении через Bun. Такая схема помогает атакующему скрыть реальное назначение файла от поверхностной проверки.
Для человека без глубокого технического опыта это можно представить так: разработчик берёт коробку с надписью известного производителя, открывает её, а внутри вместе с нужным инструментом лежит устройство, которое пытается скопировать ключи от рабочих систем. Проблема не в самой идее npm или открытого кода, а в том, что цепочка доставки пакета была использована как канал атаки.
Целью стали токены, облачные ключи и секреты CI/CD
По данным исследователей, Miasma пытался собрать широкий набор секретов: токены GitHub Actions, npm-токены, SSH-ключи, Docker-учётные данные, .env-файлы, ключи AWS, Google Cloud и Azure, Kubernetes-конфигурации, HashiCorp Vault-токены, PyPI-токены и другие чувствительные данные.
Секреты в разработке — это цифровые ключи доступа. Они позволяют публиковать пакеты, подключаться к облачной инфраструктуре, запускать сборки, управлять контейнерами, читать приватные репозитории или взаимодействовать с внутренними сервисами. Потеря такого ключа может привести к новым публикациям вредоносных пакетов, утечке исходного кода, компрометации облачных ресурсов или распространению атаки дальше по цепочке.
Именно поэтому подобные инциденты опасны даже тогда, когда заражённый пакет не используется в пользовательском продукте напрямую. Достаточно установки в среде сборки, на машине разработчика или в тестовом проекте. Если в этом окружении были доступны рабочие токены, их нужно считать потенциально скомпрометированными.
Отдельный риск связан с CI/CD. Современные проекты часто публикуют пакеты, собирают контейнеры и разворачивают приложения автоматически. Когда вредоносный код попадает в такую среду, он может увидеть больше секретов, чем обычное приложение на компьютере пользователя. Поэтому рекомендации исследователей сводятся к быстрому поиску затронутых версий, очистке окружений и ротации ключей.
Возможный путь атаки связан с GitHub Actions и trusted publishing
Aikido сообщает, что пакеты были опубликованы через GitHub Actions OIDC и механизм npm trusted publishing. По версии исследователей, атакующие получили доступ к GitHub-аккаунту сотрудника Red Hat и смогли добавить вредоносные изменения в несколько репозиториев. Эти изменения запускали workflow, который публиковал заражённые версии пакетов.
Trusted publishing создавался для снижения зависимости от долгоживущих npm-токенов. Вместо постоянного токена CI/CD-система получает краткоживущий идентификационный токен через OIDC. Это повышает безопасность при корректной настройке, но не защищает от сценария, когда злоумышленник уже контролирует репозиторий, workflow или аккаунт с правами на публикацию.
Эта деталь важна для разработчиков и DevOps-команд. Простая замена npm-токена на trusted publishing не закрывает весь риск. Нужны защита аккаунтов, обязательная многофакторная аутентификация, ограничение прав workflow, запрет обхода code review, контроль неожиданных изменений в .github/workflows, проверка provenance и мониторинг публикаций.
Инцидент продолжает волну атак Mini Shai-Hulud
Исследователи связывают Miasma с техникой Mini Shai-Hulud. Это семейство атак на цепочку поставки, которое в 2026 году уже фигурировало в сообщениях о компрометации пакетов и CI/CD-окружений. По оценке Aikido и Socket, новый вариант использует похожие идеи: выполнение при установке, кража секретов, попытки распространения через доступные учётные данные и публикацию новых заражённых версий.
При этом атрибуция остаётся осторожной. Публичная доступность инструментов Mini Shai-Hulud снижает порог входа для других групп. Поэтому факт сходства с предыдущими кампаниями ещё не означает, что за атакой стоит тот же оператор. Более надёжный вывод звучит так: злоумышленники всё активнее атакуют не только готовые приложения, но и инфраструктуру разработки, публикации и сборки.
Для бизнеса это меняет приоритеты защиты. Проверять нужно не только production-серверы, но и разработческие ноутбуки, CI/CD-раннеры, GitHub Actions, npm-публикации, lock-файлы и кэши зависимостей. Атака на пакетный менеджер может начаться далеко от пользовательского интерфейса, но последствия способны дойти до облачной инфраструктуры и цепочки релизов.
Командам нужно проверить зависимости и сменить секреты
Первый практический шаг — проверить, использовались ли в проекте затронутые пакеты и версии. Это можно сделать через package-lock.json, pnpm-lock.yaml, yarn.lock, историю CI/CD-сборок, локальные node_modules, артефакты сборки и кэши package manager.
Особое внимание стоит уделить пакетам из пространства @redhat-cloud-services. Среди затронутых в отчёте Aikido указаны, например, @redhat-cloud-services/chrome, frontend-components, insights-client, sources-client, remediations-client, rbac-client, types, vulnerabilities-client и другие пакеты. Полный список лучше сверять с актуальными индикаторами компрометации у исследователей, поскольку расследование может обновляться.
Если заражённая версия могла запускаться в окружении разработки или CI/CD, безопаснее считать секреты скомпрометированными. В таком случае нужны ротация npm-токенов, GitHub-токенов, SSH-ключей, облачных ключей, Vault-токенов, Kubernetes service account credentials и других секретов, доступных в этой среде.
Также стоит очистить кэши зависимостей, пересобрать окружения с чистого состояния и проверить историю публикаций собственных npm-пакетов. Если заражённый пакет запускался в CI/CD, простой откат package-lock.json может оказаться недостаточным: украденные токены продолжают работать, пока их не отзовут или не заменят.
Проверка цепочки поставки становится частью обычной разработки
Инцидент с пакетами Red Hat показывает, что доверие к имени организации в npm больше не может быть единственным критерием безопасности. Даже официальный namespace не гарантирует, что конкретная опубликованная версия безопасна. Для команд, которые используют JavaScript-зависимости, базовая гигиена цепочки поставки становится такой же важной, как обновление фреймворков и исправление уязвимостей.
Минимальный набор мер выглядит практично: фиксировать версии через lock-файлы, проверять новые версии перед обновлением, отслеживать lifecycle scripts, ограничивать секреты в CI/CD, применять принцип минимальных прав, включать MFA для аккаунтов разработчиков и публикации, а также использовать инструменты анализа зависимостей и malware-detection.
Для обычных пользователей прямой риск ниже, чем для разработчиков и компаний, которые собирают продукты на Node.js. Но косвенно такие атаки важны для всех: современное ПО собирается из тысяч компонентов, и компрометация одного звена может повлиять на сервисы, которыми пользуются миллионы людей.
Итог зависит от скорости проверки окружений
На момент публикации расследования продолжаются. Red Hat заявила об удалении затронутых пакетов и отсутствии выявленного воздействия на клиентские, партнёрские и production-окружения. Исследователи при этом рекомендуют организациям, которые могли установить скомпрометированные версии, действовать по сценарию потенциальной утечки секретов.
Практический вывод для разработчиков прост: проверить lock-файлы, историю установок и CI/CD-логи за 1 июня 2026 года, удалить затронутые версии, пересобрать окружения и заменить доступные секреты. Чем быстрее команда закроет токены и ключи, тем ниже шанс, что атака продолжит распространяться через уже украденные доступы.
