Mini Shai-Hulud снова напомнил, что цепочка поставки ломается не только через свежий взлом, но и через старый, плохо убранный мусор. Две сторонние GitHub Actions, ранее скомпрометированные в майской кампании, больше недели снова были доступны и по-прежнему указывали на вредоносный код, сообщает BleepingComputer. Для команд, которые доверяют CI/CD как бытовой технике, это неприятный сигнал: даже отключенный риск может вернуться, если релизные теги не вычищены.
Речь идет о репозиториях actions-cool/issues-helper и actions-cool/maintain-one-comment. По данным исследователей Socket, 16 сентября 2026 года оба действия снова стали доступны на GitHub, а их release tags продолжали вести на коммит от 18 мая с обфусцированной нагрузкой в файле index.js. Любой workflow, который ссылался на эти actions по версии, а не на проверенный commit hash, при следующем запуске мог скачать и выполнить старый вредоносный payload.
История началась 18 мая, когда эти actions были скомпрометированы в рамках кампании Mini Shai-Hulud. Тогда команда безопасности GitHub удалила actions-cool/issues-helper и actions-cool/maintain-one-comment, чтобы downstream-workflows не тянули вредоносный код. Проблема в том, что отключение репозитория не равно чистке всех ссылок, тегов и артефактов. В сентябре это отличие стало не теорией для аудита, а рабочим инцидентом.
По версии Socket, окно повторной экспозиции длилось с 16 по 25 сентября. Начало риска исследователи привязывают к промежутку между 11:09 и 18:16 по GMT+2 16 сентября. 25 сентября обе GitHub Actions снова были отключены, и workflows, которые на них ссылались, начали падать вместо того, чтобы исполнять вредоносную нагрузку. Это раздражает инженеров, но с точки зрения безопасности падение сборки лучше тихого выполнения чужого JavaScript в CI.
Масштаб пока нельзя свести к одной аккуратной цифре. В графе зависимостей GitHub около 15 000 репозиториев зависят от issues-helper, но это не значит, что все они были заражены или вообще запускали опасный код в нужный период. Socket отдельно подчеркивает: пока неизвестно, сколько проектов ссылались на эти actions именно через изменяемый тег, а не через закрепленный commit. Это важная разница. Тег удобен, читаем и привычен, но в supply chain он ведет себя как плавающая дверь: сегодня за ней один код, завтра другой.
Mini Shai-Hulud уже был заметной атакой на экосистему JavaScript. Майская кампания затронула 323 пакета и 639 версий в npm. Вредоносный код был нацелен на токены разработчиков, учетные данные и секреты CI/CD. Такой набор целей объясняет, почему GitHub Actions становятся особенно вкусной поверхностью атаки: в них часто живут доступы к registry, облакам, production-инфраструктуре, системам релиза и внутренним сервисам. Если злоумышленник получает секрет из CI, ему не нужно убеждать разработчика запускать подозрительный бинарник на ноутбуке.
Самый неприятный момент здесь не в экзотичности техники, а в ее будничности. Многие команды годами используют чужие actions как стандартные кирпичи для housekeeping: закрыть issue, поддержать один комментарий, обновить статус, поправить метку. Эти задачи выглядят низкорисковыми, почти административными. Но исполняются они в том же CI-контуре, где часто доступны токены репозитория и окружения. Поэтому маленький helper в YAML-файле может оказаться входом в гораздо более дорогую часть инфраструктуры.
Что делать разработчикам и DevOps-командам, если в проектах есть GitHub Actions из семейства actions-cool? Минимальный набор действий простой, но его лучше не откладывать. Найти ссылки на actions-cool/issues-helper и actions-cool/maintain-one-comment. Удалить их или закрепить на проверенный чистый commit, если без них нельзя жить. Проверить workflow runs с 16 сентября. Повернуть секреты, которые были доступны jobs, запускавшим эти actions по затронутым тегам. И отдельно посмотреть, не используются ли в организации другие сторонние actions по плавающим тегам вроде v1 или latest.
Для бизнеса урок еще жестче: безопасность CI/CD нельзя закрыть политикой «мы используем GitHub, значит все нормально». Платформа может отключить вредоносный репозиторий, исследователи могут быстро найти проблему, но финальная гигиена остается у владельцев пайплайнов. Нужны allowlist для actions, закрепление зависимостей по commit SHA, регулярный поиск секретов в логах и понятная процедура ротации. Это скучные меры, зато именно они решают, станет ли чужой инцидент вашим ночным созвоном.
Повторное появление Mini Shai-Hulud показывает, что атаки на цепочку поставки все чаще живут дольше первого заголовка в новостях. Старый вредоносный коммит, забытый тег и автоматический workflow могут встретиться спустя месяцы. Следующий вопрос для индустрии не в том, найдут ли еще один скомпрометированный action, а в том, сколько компаний уже умеют быстро понять, где именно он у них выполнялся.