Исследователи SafeDep раскрыли масштабную supply chain-кампанию Megalodon, в ходе которой злоумышленники за шесть часов отправили 5718 вредоносных коммитов в 5561 GitHub-репозиторий. Атака прошла 18 мая 2026 года и была нацелена не на обычных пользователей, а на CI/CD-среды: вредоносные GitHub Actions собирали токены, ключи, облачные credentials и другие секреты.
SecurityWeek пишет, что заражение шло через автоматизированные коммиты: в репозитории добавлялись или подменялись workflow-файлы GitHub Actions с payload для кражи данных. Кампания выглядела как обычное «улучшение сборки» или «оптимизация CI», но внутри запускался base64-кодированный bash-скрипт, который вытаскивал секреты из окружения и отправлял их на управляющий сервер.
GitHub Actions — это механизм автоматизации внутри GitHub. Через него проекты запускают тесты, сборки, публикацию npm-пакетов, Docker-образов, деплой в облака и другие действия. Именно поэтому атака по workflow-файлам опаснее, чем случайный вредоносный файл в репозитории. Если вредонос попадает в CI, он часто получает доступ к тому, что не лежит в исходниках: токенам публикации, облачным ролям, Docker-логинам, npmrc, SSH-ключам, переменным окружения и OIDC-токенам.
Megalodon использовал одноразовые аккаунты и поддельные авторские имена: build-bot, auto-ci, ci-bot, pipeline-bot. Коммиты маскировались под рутинное обслуживание: ‘ci: add build optimization step’, ‘build: improve ci performance’, ‘chore: optimize pipeline runtime’, ‘chore: sync ci configuration’, ‘fix: correct build workflow’. Такой текст не выглядит подозрительно в большом проекте, где автоматизация постоянно меняется.
SafeDep описывает два варианта заражения. Массовый вариант добавлял новый файл .github/workflows/ci.yml с именем workflow SysDiag и запуском на push по всем веткам, а также на pull_request_target. Более точечный вариант подменял уже существующий workflow, переименовывал его в Optimize-Build и запускал через workflow_dispatch. Оба варианта запрашивали опасные права, включая id-token: write и actions: read.
Главная добыча — секреты. Payload собирал переменные окружения CI, /proc/*/environ, окружение PID 1, AWS-ключи из профилей, GCP access tokens через gcloud auth print-access-token, данные из metadata эндпойнтов AWS, GCP и Azure, SSH private keys, Docker auth config, .npmrc, .netrc, Kubernetes configs, Vault tokens, Terraform credentials и историю shell. Дополнительно он сканировал исходники по регулярным выражениям для поиска API-ключей, JWT, PEM private keys, database connection strings и облачных токенов.
Отдельно опасна кража GitHub Actions OIDC token request URL и token. OIDC в CI/CD нужен, чтобы workflow мог получить временные облачные права без постоянных ключей. Это хорошая практика, если всё настроено правильно. Но если вредоносный workflow получает id-token: write, он может запросить токен и попытаться выдать себя за доверенный CI-процесс в облаке. В плохой конфигурации это превращает один вредоносный коммит в доступ к облачной инфраструктуре.
Управляющий сервер, указанный SafeDep, находился по адресу 216.126.225[.]129:8443. Исследователи также опубликовали индикаторы кампании: авторские email-адреса, имена ботов, названия workflow, commit messages и список затронутых репозиториев.
Megalodon быстро задел реальные пакеты. SafeDep пишет, что их движок Malysis заметил проблему через npm-пакет @tiledesk/tiledesk-server: внутри bundled GitHub Actions workflow оказался base64-кодированный bash payload. В отчёте указаны версии @tiledesk/tiledesk-server с 2.18.6 по 2.18.12 как затронутые. TechRadar также пишет, что некоторые npm-пакеты могли быть опубликованы из уже отравленных репозиториев.
The Hacker News указывает, что Megalodon похож на волну атак вокруг TeamPCP и Mini Shai-Hulud: те же интересы к секретам разработки, CI/CD, токенам публикации и автоматизированному распространению по экосистемам.
Отдельная проблема — pull_request_target. Этот триггер в GitHub Actions опасен при неправильном использовании, потому что workflow может запускаться в контексте базового репозитория и получать доступ к секретам, даже если инициатор — внешний pull request. В нормальных проектах его используют осторожно и только для задач, где код из pull request не выполняется с привилегиями. В атаках на CI/CD такой триггер часто превращается в короткий путь к секретам.
Для владельцев репозиториев проверка должна начинаться с .github/workflows. Нужно искать новые или изменённые workflow-файлы, base64-encoded bash, странные curl, wget, bash -c, eval, обращения к IP-адресам, запуск на pull_request_target, выдачу id-token: write, неожиданный workflow_dispatch, а также коммиты с типовыми сообщениями про ‘build optimization’ и ‘ci configuration’.
Командам, которые могли попасть в кампанию, придётся исходить из худшего сценария: все секреты, доступные заражённому workflow, уже скомпрометированы. Недостаточно удалить вредоносный .yml. Нужно ротировать GitHub tokens, npm tokens, Docker credentials, SSH keys, cloud access keys, Vault tokens, Kubernetes kubeconfig, Terraform credentials, OIDC trust policies и проверить облачные логи на действия от CI-ролей после 18 мая 2026 года.
Для npm-пакетов стоит проверить, какие версии были опубликованы после подозрительных коммитов, и при необходимости откатить релизы. Для облаков — посмотреть, запрашивались ли временные credentials через OIDC из неожиданных workflow, веток, репозиториев или actor names. Для GitHub — пересмотреть branch protection, required reviews для workflow-файлов, запретить прямые push в protected branches и ограничить GITHUB_TOKEN минимальными правами.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
