С 20 по 24 сентября 2026 года шесть заметных открытых проектов на GitHub получили правки от собственных ботов - внешне обычные, но содержащие вредоносный код. Новых взломов не было: изменения, занесённые в репозитории в мае, продолжали работать всё это время. Затронуты micro-app, у которого больше шести тысяч звёзд, MaaFramework, pro-components, wot-design-uni, vben-admin-thin-next и xadmin-client. В основной ветке каждого проекта до сих пор лежат файлы, запускающие вредоносную программу при открытии папки с кодом. Сентябрьские образцы побайтово совпадают с майской сборкой. Перечень составлен через поиск по коду GitHub, поэтому другие заражённые проекты могли остаться незамеченными.
Описание
Схема опирается на служебный компонент actions-cool/issues-helper, который автоматизирует работу с обращениями пользователей. Восемнадцатого мая злоумышленник перевёл все 53 метки версий этого компонента на собственные сборки. Тогда же он подменил 15 меток у соседнего компонента actions-cool/maintain-one-comment. Метки - это ярлыки, по которым разработчики подключают чужой код к своим проектам. Пока ярлык указывает на снимок с вредоносным содержимым, любой сценарий автоматизации, вызывающий компонент, выполняет чужой код. Новые записи появились одна за другой в течение двадцати минут, автор указан как Jinke Li, подписи отсутствуют. Метки никто не вернул на место. Четыре месяца спустя они по-прежнему ведут к заражённым сборкам.
Вредоносный код построен так, чтобы оставаться незаметным. Сначала он выполняет полезную нагрузку. Затем передаёт управление настоящему компоненту, поэтому шаг сборки завершается успешно и бот работает как обычно. У пяти проектов из шести заражение запускают боты для работы с обращениями: они срабатывают по расписанию или при появлении нового сообщения. В pro-components сценарий сработал при выпуске версии. Дальше вмешательство злоумышленника не нужно: заражение повторяется само, а разработчики и пользователи ничего не замечают, потому что сборки проходят штатно. В micro-app за две минуты появились две отдельные записи.
По данным StepSecurity, на сборочной машине программа считывает из памяти временный ключ доступа к репозиторию. Ключ принадлежит самому репозиторию, поэтому проверки доверия его пропускают. С его помощью в проект вносятся пять файлов. Часть из них отвечает за автозапуск в редакторах кода: разработчик скачивает обновление, открывает папку проекта, и дополнительный код запускается сам, запуская основную программу. Сборочные узлы установщик пропускает. На рабочей машине разработчика он разворачивает скрытый доступ, следит за ключами и умеет уничтожать данные.
Подмену трудно заметить при проверке. GitHub показывает такие правки как подтверждённые и подписанные служебным ботом: программа вносит их через программный интерфейс от имени самого репозитория. Сообщение о правке может копировать текст предыдущей записи, поэтому две соседние фиксации выглядят одинаково. Повторный запуск добавляет второй обработчик автозапуска в тот же файл. В micro-app так появились две записи с разницей в две минуты.
Сентябрьские случаи - продолжение майской волны Mini Shai-Hulud. Примерно через шесть часов после подмены меток был взломан служебный аккаунт в хранилище пакетов npm: оттуда разошлись 637 вредоносных версий библиотек. Обе волны используют одну среду исполнения Bun, один скрытый доступ и одни и те же файлы автозапуска. Более ранняя заражённая копия найдена в небольшом проекте my_elementPlus: она появилась примерно через восемьдесят минут после первой подмененной метки. Для шести перечисленных проектов сентябрьское заражение - первое найденное. Компании, которые подключают внешние компоненты по меткам, наследуют чужие ошибки на месяцы вперёд.
Статический разбор сентябрьского образца добавил две детали. Программа получает права администратора на сборочной машине без пароля и правит системный файл сопоставления домённых имён, отключая сервисы наблюдения за сборочными средами. Кроме того, в ней есть модуль уничтожения данных. Он стирает домашний каталог пользователя, если проверка украденного ключа возвращает отказ, если нужная версия библиотеки помечена как устаревшая или если запрос к хранилищу пакетов не проходит. Кража доступа в такой схеме легко перерастает в потерю рабочей машины, причём без возможности восстановить файлы.
Владельцам проектов стоит проверить, какие внешние компоненты подключены по меткам, и заменить ярлыки на точные, неизменяемые ссылки на проверенные сборки. Полезно просмотреть историю правок в каталогах настроек редакторов и инструментов автоматизации, а также отозвать ключи, которые использовали заражённые сценарии. Двухфакторная аутентификация и плановая смена сборочных секретов уменьшают ущерб, если один из ключей всё же попадёт к злоумышленнику. Отдельного внимания требуют боты, работающие по расписанию: они тиражируют вредоносный код, пока метки остаются подмененными.
Индикаторы компрометации
Hijacked actions
- actions-cool/issues-helper (53 tags)
- actions-cool/maintain-one-comment (15 tags)
Malicious tag commit, v3
- 147337a919d9
Payload Git blob
- 2931c1be43b0d04174636ddbff54963aec92bdeb, 500,143 bytes
setup.mjs Git blob
- 0bbd3d17062ded7c8159ffe22d0a4f3a85e4823e, 5,346 bytes
Exfiltration host
- t.m-kosche.com/api/public/otel/v1/traces
Commit search markers
- firedalazer, thebeautifulmarchoftime
Persistence
- kitty-monitor, gh-token-monitor, ~/.local/share/kitty/cat.py
Wiper trigger package
- @cap-js/openapi@1.4.1
