Megalodon: Атака на GitHub Actions викрала секрети з 5500+ репо

18 травня 2026 року відбулася масштабна кампанія атак на ланцюг поставок, відома як Megalodon. Протягом шести годин вона впровадила шкідливі робочі процеси GitHub Actions у понад 5500 репозиторіїв з відкритим вихідним кодом. Кампанія була націлена на репозиторії зі слабким захистом гілок, впроваджуючи бекдори у файли робочих процесів CI, призначені для викрадення секретів з кожного наступного запуску конвеєра, включаючи хмарні облікові дані, SSH-ключі, API-токени та OIDC-токени GitHub Actions.

Вразливість GitHub Actions

Робочі процеси GitHub Actions виконують довільні команди оболонки з доступом до кожного секрету, впровадженого в середовище CI. Коли репозиторій надає дозвіл id-token: write, робочі процеси також можуть створювати короткочасні OIDC-токени, які автентифікуються безпосередньо у хмарних провайдерів без статичних облікових даних. Це робить CI-раннер високоцінною мішенню: одне виконання робочого процесу може призвести до отримання ключів доступу AWS, токенів облікових записів служб GCP, облікових даних Azure IMDS, конфігурацій Kubernetes та всіх секретів репозиторію одночасно.

Правила захисту гілок є основним бар'єром, що запобігає несанкціонованому впровадженню робочих процесів. Репозиторії без обов'язкових перевірок запитів на злиття дозволяють будь-якому обліковому запису з доступом на запис або будь-якому прийнятому PR з публічного форку зі слабким контролем злиття вносити зміни в робочий процес безпосередньо в основну гілку. Megalodon систематично експлуатував цю прогалину в масштабах.

Техніка атаки: Poisoned Pipeline Execution (d-PPE)

Megalodon є класичною атакою прямого Poisoned Pipeline Execution (d-PPE) — класу атак CI/CD, де зловмисник з доступом на запис до репозиторію впроваджує шкідливий код безпосередньо у файли визначення робочого процесу, змушуючи систему CI виконувати команди, контрольовані зловмисником, під час наступного запуску конвеєра. На відміну від непрямого PPE (i-PPE), який вимагає запиту на злиття з форку, d-PPE експлуатує прямий доступ до основної гілки, повністю обходячи будь-яку перевірку запитів на злиття.

Ця техніка відповідає MITRE ATT&CK T1195.002 (Компрометація ланцюга поставок: Компрометація ланцюга поставок програмного забезпечення). Атака особливо ефективна, оскільки:

Файли YAML робочих процесів отримують значно менше перевірок безпеки, ніж код програми.
Повідомлення про комміти, схожі на ботів, легко вписуються у високошвидкісні репозиторії.
CI-раннери за замовчуванням мають широкий вихідний доступ до Інтернету без брандмауера.
Ефемерні середовища раннерів залишають мінімальні судові сліди після завершення завдання.

Можливості корисного навантаження

Обидва варіанти робочого процесу містять закодоване в base64 корисне навантаження bash, яке розкодовується та виконується вбудовано під час запуску CI. Корисне навантаження функціонально ідентичне в обох варіантах, відрізняючись лише умовою спрацьовування. Під час виконання воно здійснює наступну послідовність збору та ексфільтрації:

Збір облікових даних та секретів: Повний дамп середовища CI, /proc/*/environ для всіх запущених процесів та дані середовища PID 1.
Хмарні облікові дані: Ключі доступу AWS та токени сесій, токени GCP OAuth, відповіді Azure IMDS та облікові дані ролей екземплярів.
Матеріали для автентифікації: Приватні ключі SSH, конфігурації реєстру Docker (~/.docker/config.json), токени .npmrc, конфігурації Kubernetes (~/.kube/config), токени HashiCorp Vault, облікові дані Terraform.
Токени CI/CD: OIDC-токени GitHub Actions (створені за допомогою дозволу id-token: write), токени GitLab CI/CD, токени Bitbucket pipeline.
Секрети вихідного коду: Пошук у файловій системі робочої області за 30+ шаблонами секретів — API-ключі, рядки підключення, JWT, PEM-сертифікати, файли .env, credentials.json, service-account.json.

Ексфільтрація даних

Всі зібрані дані стискаються в єдиний архів і передаються через HTTPS POST на 216.126.225.129:8443. Корисне навантаження використовує вихідний доступ до Інтернету раннера GitHub Actions, який більшість середовищ CI залишають необмеженим, досягаючи C2-сервера. Жодних аномалій процесу або збоїв не видно користувачеві; крок робочого процесу завершується чисто після ексфільтрації.

Постраждалі репозиторії та організації

Кампанія торкнулася 5561 репозиторію на GitHub. SafeDep опублікував повний набір даних з 5718 шкідливих коммітів у файлі megalodon-campaign-commits.csv. Серед найбільш помітних підтверджених цілей:

Tiledesk (9 репозиторіїв) — платформа для онлайн-чату та чат-ботів з відкритим вихідним кодом. Пакет npm @tiledesk/tiledesk-server був скомпрометований у версіях 2.18.6–2.18.12; бекдор поширився на подальших споживачів через реєстр npm.
Black-Iron-Project (8 репозиторіїв) — постраждав від цільового варіанту в рамках тієї ж кампанії.
WISE-Community (підтверджено) — спільнота з відкритим вихідним кодом у галузі освітніх технологій.

Як виявити шкідливий вміст

Впроваджені файли робочих процесів використовують стандартні імена (ci.yml, docker-community-worker-push-latest.yml), щоб уникнути підозр. Поле name робочого процесу всередині файлу встановлено як SysDiag або Optimize-Build. Пошук за вмістом для виявлення постраждалих репозиторіїв можна здійснити за допомогою:

Пошуку коду GitHub: name: SysDiag in workflow files (для масового варіанту) або name: Optimize-Build in workflow files (для цільового варіанту).
Пошуку коду GitHub: filename SysDiag.yml in .github/workflows/ або filename Optimize-Build.yml in .github/workflows/.

Також можна шукати за підробленою ідентичністю автора або повідомленням комміту, щоб знайти репозиторії, які отримали шкідливі комміти:

Комміти від build-bot@github-ci.com або ci-pipeline@actions-bot.com.
Комміти з повідомленнями: "ci: add build optimization step" від build-bot, "chore: optimize pipeline runtime" від auto-ci, "chore: update ci/cd pipeline" від ci-bot.
Хеш комміту: acac5a9854650c4ae2883c4740bf87d34120c038 (якірний комміт Tiledesk).

Що це означає для розробників

Ця новина підкреслює, що CI-раннери є високоцінними цілями для викрадення облікових даних, а файли YAML робочих процесів потребують ретельнішої перевірки безпеки. Розробникам необхідно посилити захист гілок з обов'язковими перевірками запитів на злиття, щоб запобігти прямим ін'єкціям шкідливих робочих процесів.

Ключові факти

18 травня 2026 року відбулася атака Megalodon, що інфікувала понад 5500 репозиторіїв GitHub Actions.
Атака використовувала техніку Poisoned Pipeline Execution (d-PPE), експлуатуючи слабкий захист гілок.
Шкідливі робочі процеси викрадали хмарні облікові дані, SSH-ключі, API-токени та OIDC-токени.
Зібрані дані ексфільтрувалися на IP-адресу 216.126.225.129:8443 через HTTPS POST.
Серед постраждалих організацій — Tiledesk, Black-Iron-Project та WISE-Community.