GhostAction похищает секреты через вредоносные GitHub Actions
Кампания GhostAction внедрила вредоносные workflow GitHub Actions в десятки тысяч репозиториев через скомпрометированные аккаунты разработчиков. Socket на 9 октября 2026 года выявила более 500 аккаунтов, которые с 7 октября добавили такой workflow; ранее атака затронула 817 репозиториев 327 пользователей и привела к утечке 3325 секретов.
Исследователи StepSecurity зафиксировали использование аккаунта Такаси Китао, автора игрового движка pyxel с 18 400 звёздами: с него в 27 репозиториев был отправлен вредоносный файл. Спустя восемь часов аккаунт Генри Ву применили для добавления того же workflow в 318 репозиториев за 16 минут.
Как работает внедрённый workflow
Файлы маскируются под проверку безопасности и называются security-audit.yml или github_actions_security.yml. После добавления в основную ветку они могут запускаться вручную, а также при отправке изменений в любую ветку или тег.
Workflow получает код с параметром fetch-depth: 0, поэтому видит не только рабочее дерево, но и всю историю Git. Единственный шаг Audit собирает именованные секреты GitHub Actions, ищет учётные данные по 13 шаблонам в файлах и коммитах, а также сопоставляет идентификаторы ключей AWS с соответствующими секретными ключами.
Собранные данные отправляются командой curl на жёстко заданный IP-адрес 193.32.204[.]199 по обычному HTTP. В перечень потенциально похищаемых данных входят токены PyPI, npm, DockerHub, GitHub и GitLab, ключи AWS, учётные данные облачных и SaaS-сервисов, а также API-ключи Anthropic, OpenAI и OpenRouter.
Риск для форков и закрытых репозиториев
GitGuardian сообщала, что с 31 августа по 30 сентября 2026 года вредоносный workflow попал в 772 публичных репозитория 373 пользователей и организаций. Среди его целей были SSH-ключи, учётные данные Azure, Google Cloud, Firebase, Cloudflare, базы данных, FTP и токены ботов Telegram, Slack и Discord.
Socket отдельно отмечает 279 форков в пространстве имён henrywoo: файл workflow присутствует в каждом из них. Если GitHub Actions включён, последующие отправки изменений способны запустить сбор секретов. Уязвимы и новые форки, и те, что синхронизируются с затронутым исходным репозиторием.
Особое внимание требуется закрытым форкам и внутренним зеркалам: именно в приватных репозиториях чаще оказываются случайно закоммиченные учётные данные. Каждый запуск также возвращает оператору идентификатор репозитория, даже когда секреты не найдены.
Что проверить командам разработки
Разработчикам следует проверить репозитории на наличие security-audit.yml и github_actions_security.yml, добавленных с 31 августа 2026 года. Наличие одного из этих файлов следует рассматривать как признак компрометации: необходимо отозвать скомпрометированные GitHub-учётные данные, сменить секреты, удалить workflow из всех веток и проверить форки.
Для бизнеса это означает, что аудит нельзя ограничивать основным репозиторием. В проверку нужно включить историю коммитов, ветки, форки и зеркала, а ротацию токенов — выполнить для всех сервисов, чьи ключи могли находиться в коде, настройках CI/CD или секретах GitHub Actions.