1 июня 2026 года в публичном хранилище npm (менеджер пакетов для JavaScript) появились вредоносные версии библиотек, опубликованных от имени Red Hat. Код принадлежит семейству Mini Shai-Hulud: его исходники группировка TeamPCP выложила в открытый доступ ранее. Изменённые пакеты собирали ключи доступа к npm и GitHub, облачные учётные данные, а также сведения о внутренней инфраструктуре сборки. Атака относится к классу атак на цепочку поставок: злоумышленник действует не напрямую, а через доверенный компонент сборки. Риск касается прежде всего организаций, чьи конвейеры разработки зависят от сторонних библиотек.
Описание
Первые изменения внесли утром 1 июня через учётную запись разработчика с правом публикации пакетов. Позднее она же оставляла правки в служебных репозиториях Red Hat на GitHub. Файл настройки, добавленный в проект, содержал намеренно запутанный код. Прочитать его напрямую нельзя. Числовые последовательности превращались в текстовые команды, а часть строк раскрывалась только во время работы программы. Три слоя маскировки сменяли друг друга, поэтому обычная проверка файла почти ничего не давала.
О масштабе сообщила служба безопасности компании. {По данным Red Hat Product Security}, изменения затронули сотни компонентов Node.js (среда выполнения для JavaScript). Ни одна изменённая версия не вошла в выпущенные продукты Red Hat. Схема при этом воспроизводит приёмы, известные по более ранним вариантам Shai-Hulud, включая недавний вариант под названием Miasma.
Скрытая часть кода делилась на несколько уровней. Первый устанавливал на компьютер разработчика вспомогательную среду исполнения Bun - она загружалась из открытого репозитория GitHub. Второй отвечал за поиск конфиденциальных данных. Третий содержал основную полезную нагрузку. Расшифровать её без ключей, встроенных в программу, невозможно. Уже сама загрузка постороннего инструмента во время установки библиотеки выглядит подозрительно: легитимные пакеты так не поступают.
Среди целей - ключи доступа к npm, конвейерам GitHub Actions (служба автоматизации сборки), облачным платформам Amazon Web Services, Google Cloud и Microsoft Azure. Отдельно код искал данные Anthropic, Jenkins, CircleCI, BitBucket, Vercel и Netlify. Обнаружив рабочий ключ npm, программа публиковала новые вредоносные версии. Второй фактор аутентификации обойти оказалось легко: npm доверяет учётным записям GitHub.
Дальнейшее распространение шло через похищенные секреты GitHub. Червь правил чужие репозитории и добавлял в них собственные копии. На машинах разработчиков закреплялся отдельный скрипт. Он искал в GitHub коммиты со специальной меткой, проверял их подлинность по встроенному ключу и загружал найденное по ссылке из сообщения. Дополнительные модули выгружали содержимое оперативной памяти и собирали данные из процессов сборочных агентов Windows. Часть внешних файлов к моменту разбора уже удалили.
Публикация исходников Mini Shai-Hulud в открытом доступе снижает порог входа для других групп. Схему повторяют, меняя лишь детали доставки. Именно так появился вариант Miasma, замеченный в этой атаке.
Последствия ощутимы даже без прямого взлома продуктов. Украденные ключи открывают доступ к репозиториям, облачным средам и конвейерам сборки. Через них злоумышленник попадает в производственные системы. Разработчик библиотеки, которую используют тысячи проектов, превращается в удобную площадку для атаки на клиентов. Ключи нередко переиспользуют между сервисами, поэтому одна утечка открывает сразу несколько систем. Смена ключей и разбор инцидента занимают дни, а остановка конвейера сборки - часы.
Снизить риск помогает отказ от автоматического запуска сценариев при установке зависимостей. Пакеты ставят с отключёнными сценариями жизненного цикла и разрешают их только там, где без них не обойтись. Полезны пауза перед установкой только что вышедших версий, списки разрешённых библиотек, фиксация версий и анализ поведения пакетов. Инвентаризация компонентов на основе SBOM (перечень всех составляющих программного продукта) помогает быстро понять, затронут ли проект. Командам, публикующим собственные библиотеки, стоит заранее определить, кто имеет право выпускать версии.
Права рабочих процессов GitHub ограничивают по умолчанию. Расширенные разрешения выдают узкому кругу задач выпуска. Публикацию защищают обязательными проверками веток и окружений, чтобы правки в рабочих процессах не получали доступ к выпуску новых версий. Проверять стоит не только владельца репозитория, но и подписи коммитов, источник сборки, а также ожидаемый состав артефактов.
Контроль за сборочными системами и рабочими станциями разработчиков выявляет подозрительные обращения во время установки зависимостей. Настораживают попытки записи через программный интерфейс GitHub, загрузка среды Bun, обращения к облачным службам метаданных и к сервисам искусственного интеллекта. На уровне сборочных агентов следят за запуском процессов, доступом к файлам, сетевыми соединениями и оперативной памятью. Такие меры не заменяют аудит, зато дают время заметить аномалию до публикации.
Индикаторы компрометации
