Ключевой вектор атак на цепочки поставок программного обеспечения сместился в сторону автоматизации процессов разработки. В начале марта 2026 года злоумышленники, получившие доступ к учетным записям сопровождающих, провели сложную операцию по внедрению вредоносного кода в популярный инструмент безопасности для CI/CD. Инцидент с GitHub Action Xygeni наглядно демонстрирует, как уязвимости в управлении зависимостями могут превратить инструмент защиты в оружие для атак.
Описание
Атака началась 3 марта, когда в репозитории официального GitHub Action компании Xygeni, "xygeni/xygeni-action", были открыты три запроса на слияние (pull request) с идентичным вредоносным кодом. Зловредный шаг был замаскирован под легитимную функцию сбора телеметрии версий сканера. Несмотря на то, что запросы были быстро закрыты без слияния с основной веткой, атакующий достиг своей главной цели, изменив положение тега "v5" - общепринятой ссылки на мажорную версию. В течение семи дней, с 3 по 10 марта, любой проект, использовавший в своих рабочих процессах строку "uses: xygeni/xygeni-action@v5", неявно выполнял полноценный агент системы командования и управления (C2, Command and Control).
Расследование специалистов StepSecurity показало, что вредоносная нагрузка представляла собой не просто скрипт для сбора данных, а полноценный обратный шелл с возможностью удаленного выполнения команд. Внедренный код регистрировал сборочный раннер на внешнем сервере управления, передавая информацию о системе, и затем в течение трёх минут циклически опрашивал сервер на наличие команд для выполнения. Все операции выполнялись в фоновом режиме с использованием обфускации, что делало атаку практически незаметной для пользователя, так как основной рабочий процесс завершался штатно. За отведенное время злоумышленник мог похитить критически важные секреты, включая токены доступа, прочитать исходный код или модифицировать артефакты сборки.
Особенностью данной атаки стал метод её реализации, известный как «отравление меток». В экосистеме GitHub Actions распространена практика ссылаться на действия через семантические теги, такие как "@v1" или "@v2", для автоматического получения обновлений. Однако эти теги являются изменяемыми, и пользователь с правами на запись в репозиторий может переназначить их на любой коммит, включая вредоносный. В данном случае атакующий переместил тег "v5" с легитимного коммита релиза "v5.38.1" на коммит из закрытой ветки, содержащей бэкдор. В результате тысячи рабочих процессов по всему миру начали выполнять вредоносный код, при этом их конфигурационные файлы не изменились ни на символ.
Происхождение атаки указывает на компрометацию учетных данных, а не на действия инсайдера. Вредоносные запросы на слияние исходили от двух долгосрочных сопровождающих репозитория и одного официального GitHub App, принадлежащего самой Xygeni. Быстрая последовательность действий с использованием разных учётных записей в течение 23 минут говорит о том, что злоумышленник, получив доступ, пытался как можно быстрее внедрить код, переключаясь между скомпрометированными аккаунтами при блокировке предыдущих попыток.
Реакция компании Xygeni на инцидент была поэтапной. В первые часы были закрыты все подозрительные запросы на слияние и удалены рабочие процессы из репозитория. Однако критически важный шаг - исправление отравленного тега "v5" - был выполнен лишь 10 марта, после публикации анализа StepSecurity и ответственного информирования. К окончательным мерам реагирования относятся удаление скомпрометированной метки, ротация всех токенов доступа, включение иммьютабельности релизов для предотвращения изменения тегов, а также усиление политик защиты веток. Компания также выпустила полный отчёт об инциденте, подтвердив, что причиной стала кража учетных данных GitHub.
Этот случай не является единичным. Годом ранее, в марте 2025, аналогичная техника использовалась в атаке на популярный Action "tj-actions/changed-files". Оба инцидента высвечивают системную проблему безопасности в экосистеме GitHub Actions, где изменяемые метки по умолчанию представляют собой удобный, но крайне рискованный механизм управления зависимостями. Даже такие инструменты, как Dependabot, предназначенные для обновлений, не отслеживают мутации тегов, оставляя пользователей уязвимыми.
Для специалистов по безопасности и DevOps этот инцидент служит суровым напоминанием о необходимости ужесточения политик управления зависимостями. Первое и самое важное правило - всегда фиксировать версии Actions с помощью полного хэша коммита (SHA), а не тегов. В отличие от тега, хэш коммита криптографически неизменяем и гарантирует, что будет выполнен именно тот код, на который ссылается разработчик. Во-вторых, необходимо внедрять мониторинг сетевого исходящего трафика со сборочных раннеров. В данной атаке первым действием бэкдора был вызов на внешний C2-сервер, который мог быть заблокирован системами контроля. В-третьих, целесообразно проводить аудит используемых сторонних Actions и рассматривать возможность перехода на их верифицированные и безопасно настроенные форки, которые поддерживаются специализированными компаниями в области безопасности.
Инцидент с Xygeni подчёркивает, что безопасность цепочки поставок - это непрерывный процесс, а не разовая настройка. Доверие к инструменту, даже от вендора в сфере кибербезопасности, не должно быть безоговорочным. Современная практика требует многоуровневой защиты: от иммьютабельных ссылок на код до активного мониторинга поведения во время выполнения, что позволяет выявлять и останавливать атаки даже в случае компрометации исходного репозитория.
Индикаторы компрометации
C2 Server
- security-verify.91.214.78.178.nip.io (resolves to 91.214.78.178)
C2 Endpoints
- /b/in (register)
- /b/q (poll commands)
- /b/r (return results)
C2 Auth Header
- X-B: sL5x#9kR!vQ2$mN7
Poisoned Tag
- xygeni/xygeni-action@v5 -> commit 4bf1d4e19ad81a3e8d4063755ae0f482dd3baf12
Malicious Commits
- ceead6d (PR #46, signed as felix.carnicero@xygeni.io)
- 2d615f4 (PR #47, by nico-car)
- 4bf1d4e (PR #48, by xygeni-onboarding-app-dev[bot])
