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).