Три минуты в вашей системе – и все ключи доступа улетают на чужой сервер. Злоумышленники нашли новый способ взлома через GitHub Actions

Незаметная правка в одном ярлыке превратила популярный инструмент проверки безопасности в бэкдор. Злоумышленник взломал официальное действие GitHub (GitHub Action) Xygeni и внедрил полноценную оболочку удаленного управления, которая могла выполнять любые команды на серверах сборки. Специалисты StepSecurity подробно описали инцидент, который произошел 3 марта 2026 года.

Неизвестный получил доступ к учетным данным сопровождающих проекта Xygeni и внедрил вредоносный код в репозиторий xygeni/xygeni-action – официальное действие для GitHub, которым пользуются более 137 репозиториев. Главная проблема заключалась в том, что злоумышленник не изменял рабочие файлы пользователей. Вместо этого злоумышленник тихо перенаправил тег версии v5 на вредоносный коммит. Любой проект, где в рабочем процессе указано xygeni/xygeni-action@v5, начал запускать внедренный бэкдор.

Вредоносный код маскировался под шаг «сбор телеметрии версии сканера». Скрипт добавили в файл action.yml между установкой сканера и основной проверкой. На первый взгляд шаг выглядел безобидно: выводил информацию о версии инструмента. На деле код запускал скрытую оболочку удаленного управления.

После запуска действие регистрировалось на сервере управления по адресу 91.214.78.178, передавало имя узла, имя пользователя и версию операционной системы, а затем каждые несколько секунд проверяло наличие команд. Полученные команды выполнялись через eval, а результат сжимался и отправлялся обратно на сервер. Скрипт работал в фоне, поэтому основной процесс проверки безопасности продолжал выполняться как обычно и не вызывал подозрений.

За три минуты работы злоумышленник мог выполнять любые команды на сервере сборки. Среди возможных действий – кража переменных окружения, включая токены GitHub и ключи доступа, чтение исходного кода или подмена артефактов сборки.

Атака оказалась хитрее обычного внедрения кода через запрос на изменение. В репозитории действительно появилось три запроса на изменение с одинаковым вредоносным кодом, однако ни один из запросов не приняли. Вместо этого злоумышленник просто переместил тег v5 на вредоносный коммит. Такой тег можно изменить в любой момент, а большинство пользователей указывает в конфигурации именно номер основной версии.

Из-за такой схемы тысячи проектов могли начать выполнять вредоносный код без единого изменения в своих файлах. В конфигурации рабочей системы по-прежнему отображалась строка uses: xygeni/xygeni-action@v5, хотя фактический код действия уже изменился.

Журналы репозитория показывают, что вредоносные изменения появились изнутри организации. Запросы на изменение создали три разных источника: учетная запись сопровождающего nico-car, учетная запись сотрудника с подписью felix.carnicero@xygeni.io и служебное приложение GitHub xygeni-onboarding-app-dev[bot]. Все действия произошли примерно за двадцать минут. Такая последовательность указывает на компрометацию учетных данных или ключей доступа, а не на действия внутреннего злоумышленника.

Сопровождающие проекта вскоре закрыли вредоносные запросы и удалили рабочие процессы из репозитория. Однако тег v5 так и остался указывать на зараженный коммит. По состоянию на 9 марта пользователям советуют срочно перейти на версию v6.4.0 или закрепить конкретный коммит вместо тега.

Атака на Xygeni вновь показала уязвимость цепочки поставок в GitHub Actions. Теги версий можно изменять, поэтому один перенос тега способен подменить код для всех пользователей действия. Подобную схему уже применяли в 2025 году при атаке на действие tj-actions/changed-files, когда злоумышленники получили доступ к секретам тысяч репозиториев. Главный способ защиты в подобных случаях – привязывать действия GitHub не к тегам, а к конкретным идентификаторам коммитов. Коммит нельзя изменить задним числом, поэтому подмена кода через перемещение тега становится невозможной.