Megalodon – це масштабна кампанія зловмисного ПЗ у GitHub Actions, яка за даними SafeDep додала шкідливі CI/CD workflow-коміти до 5 561 публічного репозиторію приблизно за шість годин. Практичний ризик не обмежується зміненим кодом: отруєний workflow може запуститися в довіреному build-середовищі, прочитати secrets і дістатися до package publishing або cloud deployment до того, як мейнтейнер помітить коміт.
Розробникам і адміністраторам репозиторіїв варто розглядати інцидент як проблему цілісності workflow. Перше корисне питання: чи з’явився новий або змінений workflow, який може запускатися з credentials, OIDC federation, package tokens, SSH keys або доступом до self-hosted runner.
Хто під ризиком
Найбільший ризик мають мейнтейнери публічних GitHub-репозиторіїв, які прийняли підозрілі автоматизовані коміти 18 травня 2026 року, особливо з авторами, схожими на CI-ботів. Користувачі пакетів також можуть постраждати, якщо мейнтейнер публікує реліз із вже отруєного репозиторію; SafeDep навела Tiledesk як приклад переходу компрометації репозиторію до npm-версій.
| Що перевірити | Чому це важливо |
|---|---|
Зміни в .github/workflows/*.yml | Megalodon використовував зміни GitHub Actions workflow, а не звичайний payload у коді застосунку. |
Авторів комітів на кшталт build-bot, auto-ci, ci-bot або pipeline-bot | Кампанія маскувалася під рутинні CI-оновлення. |
SysDiag, Optimize-Build і неочікувані workflow_dispatch workflow | Такі шаблони можуть означати негайне викрадення secrets або прихований бекдор для запуску пізніше. |
| Cloud, deployment, npm, GitHub, SSH, Docker, Kubernetes, Vault і Terraform secrets | CI runners часто мають саме ті токени, які потрібні атакувальникам після компрометації репозиторію. |
Що намагався викрасти Megalodon
SafeDep і OX Security описують Megalodon як credential-stealing CI/CD malware. Payload шукав у runner-середовищах і конфігураційних файлах cloud keys, GitHub і npm tokens, SSH private keys, Docker і Kubernetes configuration, Vault і Terraform credentials, database strings, JWTs та інші secrets, які часто присутні під час build-процесу.
Тому простого revert недостатньо. Якщо workflow запускався, вважайте, що secrets, доступні цьому runner, могли бути прочитані. Якщо репозиторій публікує пакети, порівняйте уражені версії з чистим кодом і перевірте release artifacts перед тим, як вважати інцидент закритим.
Що зробити зараз
- Спершу зупиніть ризикову автоматизацію. Вимкніть підозрілі workflow і призупиніть package publishing з уражених репозиторіїв до завершення перевірки історії.
- Перевірте коміти та workflow-файли. Шукайте bot-like авторів, зміни workflow від 18 травня, неочікувані base64-блоки та нові triggers, які мейнтейнер не схвалював.
- Перегляньте GitHub Actions runs. Шукайте неочікувані запуски, особливо ручні або API-triggered, і зіставте їх із cloud audit logs та часом публікації пакетів.
- Ротуйте secrets після визначення масштабу. Замініть GitHub, npm, cloud, SSH, deployment, Vault, Terraform і database secrets, які були доступні виконаному workflow. Якщо ротацію зробити до видалення бекдора, той самий workflow може викрасти нові значення.
- Перевірте пристрої мейнтейнерів. Якщо використовувалися вкрадені токени або deploy keys, проскануйте робочу станцію на infostealers. Другий погляд через Gridinsoft Anti-Malware доречний перед повторним входом у чутливі developer accounts.
- Перевірте downstream packages. Якщо репозиторій публікує npm або інші пакети, звірте опубліковані версії та попередьте користувачів, якщо compromised build artifact міг потрапити в реліз.
Для ширшого контексту supply-chain response дивіться матеріали Gridinsoft про npm staged publishing controls, Packagist postinstall malware та Composer packages, переписані для викрадення CI secrets.
Пов’язана перевірка TrapDoor
Якщо команда перевіряє CI workflow poisoning, варто також переглянути TrapDoor package poisoning, який зачіпає workstations, build steps і конфіги AI coding assistants.
Суміжна перевірка для адміністраторів: якщо ваші Git workflows залежать від self-hosted сервісів, перегляньте також ризик Gogs RCE через відкриту реєстрацію, бо доступ до репозиторіїв і merge settings можуть стати шляхом до компрометації сервера.
FAQ
Megalodon – це звичайне зараження ПК?
Ні. Основний шлях – шкідливий GitHub Actions workflow у репозиторіях. Але ПК мейнтейнера все одно важливий, якщо саме з нього могли викрасти credentials.
Чи достатньо зробити revert шкідливого коміту?
Revert прибирає видиму зміну workflow, але не відкликає secrets, які runner міг уже прочитати. Спершу приберіть бекдор, потім перевірте runs і ротуйте зачеплені credentials.
Чи потрібно прибирати Tiledesk-версії з 19-21 травня?
Якщо ви встановлювали або збирали уражені Tiledesk package versions, названі SafeDep, оновіться до чистої версії та перевірте системи, де пакет або build pipeline запускався в цей період.
Що малим командам перевірити найперше?
Почніть зі змін workflow-файлів, неочікуваних Actions runs, GitHub tokens, npm tokens, cloud deployment keys і робочих станцій мейнтейнерів із доступом до репозиторію.
