Miasma показала предел доверия к цепочке поставок

Недавно раскрытый инцидент в цепочке поставок ПО вывел десятки npm-пакетов из пространства имён @redhat-cloud-services в центр активной кампании по краже учётных данных и самораспространению.

Согласно расследованию Snyk, вредоносный код обнаружен как минимум в 32 релизах пакетов, используемых компонентами и инструментами, связанными с Red Hat Hybrid Cloud Console. Полезная нагрузка запускается во время установки пакета, собирает учётные данные из окружений разработчиков и CI, а затем пытается распространяться дальше, публикуя вредоносные обновления в другие пакеты, доступные скомпрометированной учётной записи.

Кампания получила название Miasma. Исследователи называют её модифицированным потомком более раннего червя (Mini) Shai-Hulud.

Источник: https://snyk.io/blog/miasma-supply-chain-attack-malicious-code-redhat-cloud-services-npm-packages/

Что произошло#

Проблема не связана с тайпсквоттингом или отравленной зависимостью, скрытой глубоко в дереве транзитивных пакетов.

По данным Snyk, был скомпрометирован GitHub-аккаунт сотрудника Red Hat. Предположительно злоумышленник использовал этот доступ для отправки несанкционированных orphan-коммитов в легитимные репозитории и добавления минимального workflow для GitHub Actions, который запрашивал OIDC-токен и публиковал пакеты в npm.

Именно это делает инцидент особенно показательным.

Скомпрометированные пакеты публиковались из настоящих репозиториев и сопровождались корректными аттестациями происхождения SLSA. Иными словами, система сборки честно подтверждала источник артефактов. Но она не могла определить, был ли workflow, создавший эти артефакты, действительно авторизован.

Поэтому речь идёт не просто об очередном инциденте с npm. Случай демонстрирует сценарий, который часто остаётся за рамками обсуждений безопасности цепочки поставок: инфраструктура доверенной публикации способна корректно подтвердить даже вредоносный релиз, если злоумышленник получил контроль над доверенным контекстом публикации.

По имеющимся данным, вредоносные релизы появились двумя волнами 1 июня 2026 года. Большинство затронутых версий были отозваны в течение нескольких часов после раскрытия информации, хотя на момент публикации расследование ещё продолжалось.

Почему это важно#

Количество загрузок впечатляет, но реальный масштаб риска может оказаться значительно больше.

Многие затронутые пакеты используются как зависимости этапа сборки на рабочих станциях разработчиков и CI-раннерах. Именно на таких системах обычно находятся наиболее ценные для атакующих данные: облачные учётные данные, токены реестров пакетов, GitHub-токены, SSH-ключи и секреты развёртывания.

Сообщается, что вредоносный код запускается через install-time hook. Поскольку npm автоматически выполняет lifecycle-скрипты во время установки, заражение может произойти ещё до запуска прикладного кода.

По словам исследователей, вредоносное ПО собирает локальные учётные данные, перечисляет облачные идентичности и пытается найти другие пакеты, которые может публиковать скомпрометированная учётная запись. Именно эта возможность превращает компрометацию пакета в червя.

Новые версии вредоноса, судя по всему, уделяют больше внимания облачной инфраструктуре. Более ранние варианты концентрировались на краже секретов. Miasma дополнительно использует механизмы для поиска доступных облачных идентичностей и возможных путей доступа к управляющим плоскостям.

С точки зрения SOC это заметное повышение уровня угрозы. Цель состоит не только в сборе секретов, но и в картировании полномочий, которыми располагает заражённая среда.

Проблема происхождения артефактов#

Из доступных данных следует важный вывод.

Проверка происхождения сборки по-прежнему полезна. Организациям стоит продолжать проверять источники сборок, подписи и аттестации. Однако этот инцидент напоминает: provenance отвечает на гораздо более узкий вопрос, чем предполагают многие защитники.

Такая проверка может подтвердить, что артефакт был создан конкретным репозиторием и конкретным workflow.

Но она не способна самостоятельно доказать, что состояние репозитория, определение workflow, учётная запись сопровождающего или сама публикация были легитимными.

Подобная картина уже неоднократно встречалась в недавних атаках на цепочку поставок. Всё чаще злоумышленники атакуют доступ сопровождающих, системы CI/CD, права публикации и инфраструктуру идентификации, поскольку такие пути позволяют вредоносным артефактам наследовать легитимные сигналы доверия.

В результате формируется среда, где доверенная публикация необходима, но недостаточна.

Средства защиты, ограничивающиеся проверкой подписей, могут пропустить атаки, источником которых стали скомпрометированные сопровождающие или автоматизация.

Что проверить прямо сейчас#

Организациям, установившим затронутые версии, стоит рассматривать ситуацию как полноценный инцидент безопасности, а не как обычное обновление пакета.

Приоритетные проверки:

• Определить, устанавливались ли затронутые версии пакетов @redhat-cloud-services на рабочие станции разработчиков или системы CI.
• Пересобрать инвентаризацию зависимостей и выяснить, где именно эти версии попали в инфраструктуру.
• При необходимости переустановить пакеты с отключёнными install-скриптами на время расследования.
• Выполнить ротацию учётных данных, которые могли быть доступны с затронутых систем.
• Проверить права публикации npm-пакетов и доступ сопровождающих в проектах под вашим контролем.
• Провести аудит GitHub Actions workflow, способных запрашивать OIDC-токены или публиковать артефакты.
• Найти подозрительную активность публикации пакетов от имени доверенных учётных записей.

Командам также стоит анализировать активность облачных идентичностей, а не только статические секреты. Если вредоносный код смог перечислить или использовать облачные роли, одной ротации токенов может оказаться недостаточно для понимания масштаба компрометации.

С какими выводами пока не стоит спешить#

Несколько важных обстоятельств всё ещё находятся на стадии расследования.

Публичные данные указывают на компрометацию GitHub-аккаунта и несанкционированную активность workflow, однако полный путь проникновения пока не установлен. Также неизвестен окончательный масштаб дальнейшего распространения.

Слишком рано считать каждого потребителя этих пакетов скомпрометированным. Реальное влияние зависит от того, была ли установлена затронутая версия, в каком окружении она запускалась, какие разрешения имелись и какие учётные данные были доступны.

Но уже сейчас понятно, что речь идёт не о типичной атаке на реестр пакетов. В качестве механизма доставки, судя по всему, использовалась сама цепочка доверия.

Именно поэтому Miasma важна далеко за пределами затронутого пространства имён. Этот инцидент ещё раз показывает: безопасность open source зависит не только от целостности артефактов. Доступ сопровождающих, контроль идентичностей, управление workflow и операционный мониторинг входят в ту же самую границу доверия.

Для команд, оценивающих риски цепочки поставок ПО, это сигнал, который нельзя игнорировать.