Отчет об инциденте безопасности: xygeni-action GitHub Action Compromise

Управляющее резюме

3 марта 2026 года Xygeni обнаружила подозрительную активность, затрагивающую репозиторий, используемый для публикации GitHub Action xygeni/xygeni-action. Активность исходила от скомпрометированных учетных данных, связанных с токеном сопровождающего и приложением GitHub, установленным в репозитории.

В ходе инцидента злоумышленник попытался внедрить вредоносный код в репозиторий с помощью ряда методов. pull requestsЭти попытки были заблокированы существующими правилами защиты ветвей, что препятствовало слиянию кода с основной веткой репозитория.

Однако впоследствии злоумышленник использовал другой вектор атаки, переместив изменяемый тег v5 таким образом, чтобы он ссылался на вредоносный объект. commit созданный во время pull request попытки. Таким образом, рабочие процессы, ссылающиеся на xygeni/xygeni-action@v5, могли получить скомпрометированный код без каких-либо видимых изменений в определениях своих рабочих процессов.

Подделка метки была выявлена ​​9 марта после сообщений от населения. Поддельная метка была немедленно удалена, и были начаты процедуры реагирования на инцидент.

В ходе нашего расследования было установлено следующее:

• В основную ветку репозитория не был вложен вредоносный код.
• Там есть Нет никаких признаков компрометации платформы Xygeni SaaS. или данные клиентов.
• Период действия ограничений ограничивался рабочими процессами, ссылающимися на xygeni/xygeni-action@v5, в промежутке между 3 марта и 9 марта 2026 г..
• Взломанный тег был безвозвратно удален и не будет создан заново.

После обнаружения манипуляций с тегами компания Xygeni внедрила ряд улучшений безопасности в своих репозиториях и процессах выпуска релизов, в том числе:

• Удаление скомпрометированного тега и рекомендации по миграции. Ссылки, закрепленные с помощью SHA.
• Исполнение освобождение неизменности по всем репозиториям.
• Ужесточение прав доступа к репозиторию и прав доступа участников проекта.
• обязательное криптографически подписанный commits для сопровождающих.
• Ограничение доступа на запись для ограниченного круга сопровождающих и администраторов.

Мы публикуем этот отчет, чтобы обеспечить прозрачность инцидента, поделиться извлеченными уроками и помочь укрепить методы обеспечения безопасности во всей экосистеме GitHub Actions.

Хотя атака использовала известную уязвимость GitHub Actions, связанную с изменяемыми тегами, инцидент также подчеркивает важность всесторонней защиты репозиториев, строгого управления учетными данными и многоуровневой защиты. CI/CD систем.

Прозрачность и сотрудничество имеют решающее значение для повышения устойчивости цепочки поставок программного обеспечения.

Обзор инцидента

В этом отчете документируется расследование инцидента, связанного с нарушением безопасности и затронувшего общественность. xygeni/xygeni-action Репозиторий GitHub Action.

3 марта 2026 года злоумышленник, используя скомпрометированные учетные данные, связанные с автоматизацией репозитория, внедрил вредоносный код посредством серии атак. pull request попытки. Полезная нагрузка содержала командно-контрольный имплантат, замаскированный под телеметрию сканера.

Правила защиты ветвей репозитория успешно предотвратили слияние вредоносного кода в репозиторий. Основная отрасльОднако впоследствии злоумышленник манипулировал изменяемым значением. v5 деньперенаправляя его на commit Содержит внедренную полезную нагрузку. Поскольку многие рабочие процессы ссылаются на GitHub Actions с использованием тегов основных версий, это отравление метки разрешенные последующие рабочие процессы со ссылками xygeni/xygeni-action@v5 чтобы получить скомпрометированный код без каких-либо видимых изменений в конфигурации рабочего процесса.

Как поставщик software supply chain security инструментыКомпания Xygeni управляет инфраструктурой, которая напрямую интегрируется в процесс разработки. pipelines и CI/CD среды. Проекты в этой области часто становятся мишенью атак, целью которых является компрометация широко используемых инструментов разработчиков для доступа к нижестоящим средам.

Лента

Этап 1: Злобные Pull Requests (3 марта, 10:22–10:50 UTC)

В 10:22 UTC 3 марта 2026 года злоумышленник начал быструю скоординированную атаку на репозиторий xygeni-action, используя две скомпрометированные учетные записи: персональный токен доступа (PAT) сопровождающего проекта и закрытый ключ приложения GitHub (xygeni-onboarding-app-dev). В течение следующих 28 минут три pull requests были созданы и закрыты, при этом каждый из них внедрял обфусцированный шелл-код в файл action.yml.

Подход злоумышленника был методичным и адаптивным:

• PR № 46 (10:22–10:29 UTC): Создано скомпрометированным сопровождающим PAT в ветке feat/canner-телеметрияЗлоумышленник попытался выполнить слияние, но его попытка была заблокирована правилами защиты ветвей. Запрос на слияние был закрыт без выполнения.
• разведывательный (10:39–10:40 UTC): Злоумышленник проверил доступ к приложению GitHub, создав и сразу же удалив ветку с именем доступ к тестовому приложениюЭто подтвердило, что приложение имеет права на запись в репозиторий.
• PR № 47 (10:41–10:44 UTC): Вторая попытка с использованием PAT сопровождающего проекта, теперь в переименованной ветке. улучшение/телеметрия сканера. Снова заблокировано защитой ветки. Злоумышленник попытался использовать приложение GitHub для одобрения запроса на слияние — обойдя требование о двух рецензентах, позволив одному скомпрометированному пользователю одобрить работу другого. Это тоже не удалось.
• PR № 48 (10:45–10:49 UTC): Роли поменялись — приложение GitHub создало запрос на слияние (отправило его). commit 4bf1d4e), и специалист по поддержке PAT подал заявку на утверждение. Эта заявка также была отклонена службой защиты филиалов.

Ни один из запросов на слияние не дошёл до основной ветки. Наши правила защиты веток оставались в силе: требование двух подтверждений, правило, согласно которому последний push должен быть одобрен кем-то, кроме отправителя, и ограничение на обход этих настроек — всё это в совокупности блокировало все попытки слияния.

Наша команда обнаружила аномальную активность во время планового анализа запросов на слияние и инициировала реагирование на инцидент в 12:21 UTC — менее чем через два часа после первого вредоносного запроса на слияние. Реагирование включало удаление рабочих процессов, сохранение вредоносного кода для криминалистического анализа и обеспечение безопасности репозитория.

Этап 2: Отравление меток

Хотя защита ветвей успешно предотвратила проникновение вредоносного кода в основную ветку, злоумышленник использовал другой вектор атаки. Используя скомпрометированные учетные данные приложения GitHub, злоумышленник переместил изменяемый тег v5 таким образом, чтобы он указывал на commit 4bf1d4e — злонамеренный commit из запроса на слияние #48, который все еще существовал в хранилище объектов репозитория даже после удаления ветки запроса на слияние.

Важно отметить, что эта манипуляция с тегами произошла не сразу после запросов на слияние. Журналы активности репозиториев GitHub не отображают события принудительной отправки тегов так же, как операции с ветками, что ограничивает возможность восстановления точной метки времени изменения тега. Однако было подтверждено, что тег был «отравлен», когда сообщество подняло тревогу 9 марта.

Ключевой вывод таков: правила защиты ветвей не защищают теги. commit В базе данных объектов Git репозитория содержался бэкдор, и тег v5 — на который ссылались последующие рабочие процессы — мог быть незаметно перенаправлен на него. Любой рабочий процесс, использующий xygeni/xygeni-action@v5, загружал бы скомпрометированный код без каких-либо видимых изменений в основной ветке или в файлах рабочих процессов использующих репозиториев.

Основная причина

В ходе нашего расследования был сделан вывод, что первопричиной стала компрометация закрытого ключа приложения GitHub (xygeni-onboarding-app-dev), установленного в репозитории.

Это приложение GitHub изначально создавалось для тестирования процесса адаптации новых пользователей на платформе Xygeni. Оно имело права на запись в репозиторий — права, которые, как оказалось впоследствии, были шире, чем необходимо для его предполагаемого назначения.

Имея приватный ключ приложения GitHub, злоумышленник может:

• Генерируйте по своему усмотрению кратковременные токены установки.
• Создать и утвердить pull requests
• Push commitчерез Git по протоколу HTTPS
• Метки перемещения — важнейшее действие, благодаря которому этот инцидент имел такое значение.

Злоумышленник использовал скомпрометированный PAT-доступ для сопровождающих проекта и учетные данные приложения GitHub в скоординированной попытке: когда одной учетной записи не удавалось обойти защиту самостоятельно, использовались обе учетные записи одновременно — одна для создания проекта, другая для его утверждения.

Точный механизм утечки закрытого ключа до сих пор расследуется. Утечка закрытых ключей GitHub App (.pem-файлов) может происходить из-за неправильно настроенных рабочих процессов, скомпрометированных машин разработчиков или небезопасного хранилища секретных данных.

Вредоносное поведение полезной нагрузки

Внедренный код представлял собой компактный командно-контрольный имплант. Он был разработан для бесшумной работы параллельно с легитимным сканером и выполнялся в три этапа:

• Регистрация. Имплант связывается с сервером управления и контроля (C2) по адресу 91.214.78.178 (замаскированным с помощью DNS-сервера nip.io под адрес security-verify.91.214.78.178.nip.io), отправляя имя хоста, имя пользователя и версию операционной системы.
• Цикл опроса. В течение 180 секунд (что соответствует типичным таймаутам заданий CI) имплант опрашивает сервер C2 каждые 2–7 секунд на наличие команд для выполнения.
• Выполнение команд. Все полученные команды выполняются через eval, при этом выходные данные сжимаются (zlib), кодируются в base64 и передаются обратно на сервер управления и контроля (C2).

Названия переменных были намеренно лаконичными, а интервал опроса рандомизирован, чтобы избежать обнаружения закономерностей трафика.

Если бы имплантат запускался на CI-сервере, злоумышленник получил бы доступ к GITHUB_TOKEN, секретам репозитория, исходному коду и, возможно, ключам подписи артефактов. Имплантат мог бы позволить выполнение команд на CI-сервере, если бы он выполнялся в рамках рабочего процесса, ссылающегося на скомпрометированный тег.

На данный момент у нас есть Нет никаких доказательств того, что полезная нагрузка была выполнена в какой-либо среде CI заказчика. или что в результате этих действий были раскрыты секреты.

Инфраструктура C2

Сервер управления и контроля (C2) размещался в компании Partner Hosting LTD (AS215826), зарегистрированной по адресу: 71-75 Shelton Street, Covent Garden, London — это широко используемый виртуальный офисный адрес. Инфраструктура была недавно развернута (подсеть последний раз изменялась всего за 5 дней до атаки), и IP-адрес уже был связан с RAT-программами, программами для кражи информации и загрузчиками в источниках информации об угрозах. Инфраструктура и инструменты указывают на то, что злоумышленник был опытным и хорошо знаком с современными технологиями. CI/CD сред.

Оценка воздействия

Ключевые наблюдения

Изменяемые метки представляют собой известный риск, но инерция обладает огромной силой.

В экосистеме GitHub Actions существует хорошо задокументированная проблема: изменяемые теги. Когда пользователи ссылаются на action@v5, они уверены, что тег указывает на безопасный код. Но теги могут быть принудительно добавлены любым пользователем с правами на запись. Это основной вектор атак на цепочку поставок GitHub Actions, и мы это знали — тем не менее, наша документация по-прежнему направляла пользователей к @v5.

Защита филиалов — это не защита меток.

Наши правила защиты ветвей сработали именно так, как и было задумано. Они предотвратили слияние вредоносного кода в основную ветку. Но злоумышленнику не нужно было выполнять слияние — ему достаточно было просто... commit в репозитории (который доступен в любой ветке запроса на слияние) и возможность перемещать теги. Защита веток создала у нас ложное ощущение всеобъемлющей безопасности.

Новые функции не обеспечивают защиту задним числом.

GitHub представил освобождение неизменности В октябре 2025 года появится функция, которая предотвращает изменение тегов, связанных с релизами. Мы знали об этом, но не до конца понимали последствия:

• Эта защита распространяется только на теги, связанные с релизами GitHub, а не на отдельные теги.
• Защита не распространяется на предыдущие версии — существующие релизы, созданные до включения этой функции, остаются изменяемыми.
• Правила защиты тегов (отдельная функция) необходимо настраивать независимо.

Если бы мы включили неизменяемость релизов и убедились, что тег v5 связан с защищенным релизом, то попытка отравления тега завершилась бы неудачей.

Чрезмерно разрешительные области видимости в GitHub App.

Приложение GitHub имело права на запись, превышающие его операционные потребности. В сложной организации с множеством приложений, ботов и интеграций легко накапливать разрешения сверх необходимого. Каждое дополнительное разрешение — это дополнительная поверхность для атаки.

Исправления к публичной записи

Отчет исследователей сыграл решающую роль в привлечении внимания общественности, и мы ценим их оперативную реакцию. Однако наше внутреннее расследование выявило некоторые детали, которые отличаются от их версии:

• Хронология отравления меткиВ отчете исследователя указано, что перемещение тега v5 произошло приблизительно в 10:49 UTC 3 марта, сразу после закрытия запросов на слияние. Наше расследование не смогло подтвердить это время — события принудительной отправки тега не регистрируются в журнале активности репозитория GitHub. Известно лишь, что тег был отравлен в какой-то момент после вредоносной атаки. commit был создан, и сообщество обнаружило его 9 марта.
• commit не был "подписан адресом электронной почты сопровождающего". В отчете исследователя описывается первый злонамеренный случай. commit Как будто «подписано адресом электронной почты сопровождающего», но это смешивает метаданные автора Git с криптографической подписью — это принципиально разные вещи. commit не был криптографически подписан. Злоумышленник просто установил в поле "Автор Git" адрес электронной почты другого сопровождающего — это может сделать любой, поскольку метаданные автора Git предоставляются самим пользователем и не требуют аутентификации. commit Обновление было отправлено с использованием скомпрометированного PAT-адреса сопровождающего; адрес электронной почты сопровождающего, который был использован, не был скомпрометирован и появляется в журнале активности репозитория только начиная с 12:21 UTC в составе группы реагирования на инцидент.
• Участвующие лицаИсследователь описал личность сопровождающего проекта и бота GitHub App как доказательство «кражи учетных данных, а не действий инсайдера». Мы можем подтвердить, что классический PAT сопровождающего проекта и закрытый ключ GitHub App были скомпрометированы. Оба использовались одним и тем же внешним злоумышленником. Запрос на слияние #48 отображается под учетной записью фантома, потому что он был создан при установке GitHub App, а не удаленной учетной записью пользователя.
• Количество затронутых репозиториевВ отчете исследователя упоминалось более 137 репозиториев, использующих @v5. Наш анализ результатов поиска кода на GitHub не подтвердил эту цифру. На момент нашего последнего анализа мы не обнаружили ни одного публичного репозитория, активно использующего xygeni/xygeni-action@v5 в исполняемых рабочих процессах. Выявленные ссылки соответствовали примерам документации в репозиториях Xygeni, которые с тех пор были обновлены. На практике большинство клиентов используют загрузку сканера через CLI и функцию управляемого сканирования Xygeni, которая внутренне вызывает действие и использует версию с SHA-фиксацией и внутренней проверкой, на которую не влияют манипуляции с тегами. Поскольку GitHub Code Search индексирует только публичные репозитории, мы не можем со 100% уверенностью определить, могли ли частные репозитории ссылаться на этот тег. На основании имеющейся информации фактическая степень распространения, по-видимому, значительно ниже, чем сообщалось изначально.

[Мы обновим этот раздел по завершении нашего расследования.]

Ответные действия

Незамедлительный ответ (3 марта)

• Вредоносные запросы на слияние были отмечены и заблокированы (защита ветки предотвратила слияние).
• Вредоносный код был извлечен и сохранен для проведения криминалистического анализа.
• Домен управления и IP-адрес, зафиксированные как индикаторы компрометации.
• Взлом приложения GitHub (xygeni-onboarding-app-dev) был удалён из репозитория.
• Все участники программы PATs были ротированы.
• Были проверены журналы аудита репозитория — никаких признаков ранее несанкционированных слияний не обнаружено.

Руководство по исправлению ситуации

Работы по рекультивации (9–10 марта)

• Взломанный тег v5 был удалён.
• Освобождение от неизменности Эта функция была включена для репозитория и применялась глобально ко всем репозиториям, принадлежащим Xygeni.
• Правила защиты филиалов были ужесточены, включая обязательное подписание соответствующих документов. commits (Xygeni использует аппаратную поддержку) commit (подпись)
• Метка v5 намеренно не была воссоздана, чтобы дать понять, что она была скомпрометирована, и чтобы стимулировать переход на ссылки с закрепленными SHA-хешами.
• Документация была обновлена, чтобы содержать полную информацию. commit SHA (13c6ed2797df7d85749864e2cbcf09c893f43b23), соответствующий версии 6.4.0
• В качестве меры предосторожности функция GitHub Actions была временно отключена в репозитории.
• Права на запись были ограничены — доступ на запись сохранили только два назначенных сопровождающих и два администратора репозитория.

Для пользователей xygeni-action

Если вы использовали xygeni/xygeni-action@v5, вам следует:

• Немедленно обновите ваш рабочий процесс для закрепления в сейфе commit ША:

uses: xygeni/xygeni-action@13c6ed2797df7d85749864e2cbcf09c893f43b23

• Проведите аудит журналов CI. для любых исходящих соединений с 91.214.78.178 или security-verify.91.214.78.178.nip.io в период с 3 по 9 марта 2026 года.
• Поверните все секреты которые контактировали с бегунами с коагуляцией в течение этого периода.
• В качестве альтернативы вы можете использовать прямая загрузка и проверка сканера

Почему мы не раскрыли эту информацию публично 3 марта

На этот вопрос мы обязаны дать честный ответ.

3 марта, когда наша команда отреагировала на вредоносные запросы на слияние (PR), оценка показала, что атака была полностью локализована на этапе PR. Правила защиты ветвей сработали. В основной репозиторий не был добавлен вредоносный код. Ни один из CI-раннеров не выполнил полезную нагрузку. Компрометированный PAT был перенесен на другую ветку, приложение GitHub было удалено, а журналы аудита репозитория не показали никаких признаков предыдущих несанкционированных слияний. Инцидент был классифицирован как инцидент средней степени серьезности (P2) — заблокированная попытка вторжения.

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

Мы упустили из виду отравление метки. Метка v5 была незаметно перемещена таким образом, чтобы указывать на вредоносную программу. commitОднако это не было видно на тех же поверхностях аудита, которые мы проверяли. Журналы активности репозиториев GitHub регистрируют изменения тегов иначе, чем операции с ветвями, что сделало модификацию менее заметной во время первоначального расследования. Наше реагирование на инцидент было сосредоточено на видимом векторе атаки — pull requests и в главном отделении — и не проверяли, не были ли повреждены бирки.

Оглядываясь назад, можно сказать, что это один из ключевых уроков этого инцидента: нельзя разглашать то, о чём не знаешь. Наша реакция 3 марта была быстрой и эффективной против видимой угрозы. Но у злоумышленника был второй, более скрытый способ проникновения, который оставался незамеченным в течение шести дней — пока его не обнаружило сообщество.

Публичное раскрытие информации (9 марта)

9 марта 2026 года члены сообщества подняли этот вопрос. #54Исследователи поставили под сомнение вредоносный код и скомпрометированный тег v5. Они опубликовали подробный анализ, который помог повысить осведомленность в масштабах всей экосистемы.

Мы хотим отметить роль исследователя в распространении предупреждения и предоставлении практических рекомендаций пострадавшим пользователям. Мы также хотим уточнить некоторые детали из его отчета, по которым наше внутреннее расследование пришло к иным выводам — мы рассматриваем эти вопросы в разделе «Исправления».

Уроки для экосистемы

• Закрепляйте действия по SHA, а не по тегу.Изменяемые теги представляют собой самую большую уязвимость в экосистеме GitHub Actions. Используйте действие@ во всех производственных процессах.
• Разберитесь в ограничениях каждой функции безопасности.Защита ветвей защищает ветви. Защита тегов защищает теги. Неизменяемость релизов защищает релизы. Они не взаимозаменяемы, и именно пробелы между ними являются местом, где действуют злоумышленники.
• Неустанно проверяйте разрешения в приложении GitHub.Каждое установленное приложение с правами на запись является потенциальным вектором горизонтального перемещения. Применяйте принцип минимальных привилегий, меняйте ключи доступа и периодически проверяйте, какие приложения установлены в критически важных репозиториях.
• Относитесь к участникам программы CI как к враждебной среде.Мониторинг исходящего сетевого трафика, временные исполнители и изоляция секретов являются обязательными для репозиториев в цепочке поставок программного обеспечения.
• Внедрение новых функций безопасности требует активного подхода.Функция неизменяемости релизов GitHub была доступна за несколько месяцев до этого инцидента. Функции, которые не включены, не обеспечивают никакой защиты — безопасность не является параметром по умолчанию.
• неподписанный commitмогут быть поддельные личности. Гит commit автор и commitПоля ввода являются самоотчетными — любой может установить в них любое значение. Без криптографических ограничений. commit При использовании подписи (GPG, SSH или S/MIME) нет гарантии, что commit На самом деле, автором был тот, за кого себя выдает. В этом инциденте злоумышленник указал автора первого вредоносного кода. commit На электронный адрес другого сопровождающего, что приводит к ложному указанию авторства. Требуется подписанная подпись. commitИспользование правил защиты ветвей устраняет этот вектор.
• Сложность увеличивает поверхность атаки.Взаимодействие между PAT, GitHub Apps, правилами защиты ветвей, семантикой тегов и неизменяемостью релизов создало среду, в которой злоумышленник обнаружил уязвимости, которые не были устранены ни одной из этих функций по отдельности. Упрощайте там, где это возможно. Понимайте полную модель угроз, даже если это невозможно.

Индикаторы компрометации (IOC)