Кампания GhostAction превратила доверие к аккаунтам разработчиков в инструмент массовой кражи данных. Злоумышленники получили доступ как минимум к двум заметным аккаунтам мейнтейнеров, внедрили вредоносный GitHub Actions workflow в сотни репозиториев, а затем с помощью более чем 500 учетных записей распространили тот же код в десятки тысяч проектов. Атакующих интересуют секреты GitHub Actions, ключи облачных платформ и ИИ-сервисов, токены пакетных реестров, учетные данные исходных систем и доступы к инфраструктуре. В отдельных случаях скомпрометированные репозитории могли использоваться для майнинга криптовалюты.
Первым из известных аккаунтов стал профиль Takashi Kitao, связанный с проектом pyxel, у которого около 18 400 звёзд GitHub. По данным StepSecurity, злоумышленники начали действовать с аккаунта Kitao в 13:20 UTC и отправили вредоносный workflow в 27 репозиториев. Второй целью оказался Henry Wu, владелец аккаунта henrywoo и первоначальный автор athenadriver компании Uber. С его аккаунта тот же workflow попал в 318 репозиториев за 16 минут, с 21:10 до 21:26 UTC. Эта операция началась примерно через восемь часов после атаки с аккаунтом Takashi Kitao. Вместе два профиля использовали для атаки как минимум 345 репозиториев.
По сведениям Socket, опубликованным 9 октября 2026 года, более 500 аккаунтов GitHub уже закоммитили вредоносный workflow, а зараженные файлы появились в десятках тысяч репозиториев. Новая волна активности наблюдалась с 7 октября 2026 года. Сама операция GhostAction стала известна ещё в сентябре 2025 года. В ходе ранее зафиксированной части кампании пострадали 817 репозиториев и 327 пользователей GitHub], а число похищенных секретов достигло 3325. Среди них были токены PyPI, npm и DockerHub.
Для маскировки использовались названия, похожие на инструменты проверки безопасности: Security Audit с файлом security-audit.yml и GitHub Actions Security с файлом github_actions_security.yml. Их помещали в ветку репозитория по умолчанию и коммитили от имени настоящего владельца или мейнтейнера. Из-за этого файл мог выглядеть как обычная защитная автоматизация, особенно в проектах, где workflow регулярно проверяют код и зависимости.
Запуск вредоносной задачи возможен вручную через workflow_dispatch, но опаснее неограниченное событие push. Оно срабатывает при отправке изменений в любую ветку или тег, поэтому обычный коммит способен активировать сбор данных. Workflow использует fetch-depth: 0: GitHub Actions загружает всю историю Git, а не только последний коммит. Удалённый из текущих файлов пароль или ключ при этом может сохраниться в старых версиях и попасть в поле зрения злоумышленников.
Внутри задачи с названием Audit выполняются четыре связанные операции: проверка файлов workflow, поиск секретов в рабочем дереве, просмотр полной истории Git и отправка найденного содержимого. Сценарий ищет данные в конфигурациях, исходном коде и старых коммитах. Затем встроенная нагрузка использует curl и передаёт результаты на сервер 193.32.204[.]199. Передача идёт по обычному HTTP, без шифрования HTTPS. Точка указана в отчётах с обозначением [.], чтобы не создавать прямую ссылку и не провоцировать случайное обращение к адресу.
Всего workflow распознаёт 2577 типов секретов. В перечень входят ключи доступа AWS, учетные данные Azure и Google Cloud, ключи Firebase и Cloudflare, FTP- и database-доступы. Проверяются учетные данные DockerHub, GitHub Container Registry (GHCR), npm и PyPI, токены GitHub и GitLab, приватные SSH-ключи, а также ключи Anthropic, OpenAI, OpenRouter и других ИИ-провайдеров. Под ударом оказываются токены ботов Telegram, Slack и Discord, именованные секреты GitHub Actions, CI/CD-учетные данные и прочие параметры автоматических сборок и развертываний. Отдельный поиск в самих workflow-файлах позволяет атакующим проверять, не оставлены ли ключи прямо в конфигурации CI.
Риск не ограничивается исходным репозиторием. В пространстве henrywoo насчитывается 279 форков, и, согласно опубликованным данным, в каждом присутствует вредоносный файл. Если GitHub Actions включён, последующий push в такой форк может снова запустить сборщик секретов. Заражение способно перейти в новые форки, зеркала и downstream-репозитории при создании копии, синхронизации с upstream или продолжении выполнения Actions после получения изменённого workflow. Частные репозитории особенно опасны: в них чаще хранятся рабочие ключи, а полный Git-история позволяет извлекать данные, которые владельцы давно удалили из актуальных файлов.
Workflow возвращает атакующим идентификатор репозитория даже в том случае, если секреты не найдены. Так злоумышленники проверяют доступность среды выполнения и формируют карту пригодных для запуска репозиториев. Такой механизм даёт им отдельный перечень активных и доступных окружений: репозиторий может оказаться полезным как вычислительная площадка или точка дальнейшего проникновения, даже если в нём нет подходящих ключей. Кража учетных данных здесь совмещена с разведкой GitHub-инфраструктуры.
30 августа 2026 года был зафиксирован ещё один сценарий использования доступа. В репозитории kuafuai/DevOpsGPT атакующие изменили проект и встроили майнер XMRig в Docker-образ. XMRig часто применяют для добычи криптовалют, включая ориентированный на приватность Monero. При этом на момент публикации исследователи не обнаружили вредоносных релизов пакетов, опубликованных с помощью украденных учетных данных. Сам факт отсутствия таких релизов не отменяет необходимости проверять npm, PyPI, DockerHub и другие реестры.
Искать подозрительные workflow следует начиная с 31 августа 2026 года. Наличие security-audit.yml или github_actions_security.yml нужно рассматривать как возможный признак компрометации. Сначала следует отозвать токен или другую учетную запись GitHub, затем заменить все потенциально доступные облачные ключи, токены реестров, API-ключи, CI/CD-секреты, SSH-ключи, пароли баз данных и токены коммуникационных сервисов. Вредоносный файл требуется удалить из ветки по умолчанию, остальных веток, тегов и других ссылок репозитория.
Проверка должна охватывать публичные и частные форки, зеркала и синхронизированные копии, прежде всего 279 форков в пространстве henrywoo. В истории Git нужно искать старые ключи, потому что fetch-depth: 0 открывает workflow полный набор коммитов. В журналах GitHub Actions стоит проверить неожиданные запуски, исходящие соединения и команды curl. Отдельно следует осмотреть Docker-образы и конфигурации сборки на наличие посторонних изменений, включая XMRig, а также сверить историю публикаций пакетов и контейнеров с журналами владельцев.
Изображение носит иллюстративный характер
Первым из известных аккаунтов стал профиль Takashi Kitao, связанный с проектом pyxel, у которого около 18 400 звёзд GitHub. По данным StepSecurity, злоумышленники начали действовать с аккаунта Kitao в 13:20 UTC и отправили вредоносный workflow в 27 репозиториев. Второй целью оказался Henry Wu, владелец аккаунта henrywoo и первоначальный автор athenadriver компании Uber. С его аккаунта тот же workflow попал в 318 репозиториев за 16 минут, с 21:10 до 21:26 UTC. Эта операция началась примерно через восемь часов после атаки с аккаунтом Takashi Kitao. Вместе два профиля использовали для атаки как минимум 345 репозиториев.
По сведениям Socket, опубликованным 9 октября 2026 года, более 500 аккаунтов GitHub уже закоммитили вредоносный workflow, а зараженные файлы появились в десятках тысяч репозиториев. Новая волна активности наблюдалась с 7 октября 2026 года. Сама операция GhostAction стала известна ещё в сентябре 2025 года. В ходе ранее зафиксированной части кампании пострадали 817 репозиториев и 327 пользователей GitHub], а число похищенных секретов достигло 3325. Среди них были токены PyPI, npm и DockerHub.
Для маскировки использовались названия, похожие на инструменты проверки безопасности: Security Audit с файлом security-audit.yml и GitHub Actions Security с файлом github_actions_security.yml. Их помещали в ветку репозитория по умолчанию и коммитили от имени настоящего владельца или мейнтейнера. Из-за этого файл мог выглядеть как обычная защитная автоматизация, особенно в проектах, где workflow регулярно проверяют код и зависимости.
Запуск вредоносной задачи возможен вручную через workflow_dispatch, но опаснее неограниченное событие push. Оно срабатывает при отправке изменений в любую ветку или тег, поэтому обычный коммит способен активировать сбор данных. Workflow использует fetch-depth: 0: GitHub Actions загружает всю историю Git, а не только последний коммит. Удалённый из текущих файлов пароль или ключ при этом может сохраниться в старых версиях и попасть в поле зрения злоумышленников.
Внутри задачи с названием Audit выполняются четыре связанные операции: проверка файлов workflow, поиск секретов в рабочем дереве, просмотр полной истории Git и отправка найденного содержимого. Сценарий ищет данные в конфигурациях, исходном коде и старых коммитах. Затем встроенная нагрузка использует curl и передаёт результаты на сервер 193.32.204[.]199. Передача идёт по обычному HTTP, без шифрования HTTPS. Точка указана в отчётах с обозначением [.], чтобы не создавать прямую ссылку и не провоцировать случайное обращение к адресу.
Всего workflow распознаёт 2577 типов секретов. В перечень входят ключи доступа AWS, учетные данные Azure и Google Cloud, ключи Firebase и Cloudflare, FTP- и database-доступы. Проверяются учетные данные DockerHub, GitHub Container Registry (GHCR), npm и PyPI, токены GitHub и GitLab, приватные SSH-ключи, а также ключи Anthropic, OpenAI, OpenRouter и других ИИ-провайдеров. Под ударом оказываются токены ботов Telegram, Slack и Discord, именованные секреты GitHub Actions, CI/CD-учетные данные и прочие параметры автоматических сборок и развертываний. Отдельный поиск в самих workflow-файлах позволяет атакующим проверять, не оставлены ли ключи прямо в конфигурации CI.
Риск не ограничивается исходным репозиторием. В пространстве henrywoo насчитывается 279 форков, и, согласно опубликованным данным, в каждом присутствует вредоносный файл. Если GitHub Actions включён, последующий push в такой форк может снова запустить сборщик секретов. Заражение способно перейти в новые форки, зеркала и downstream-репозитории при создании копии, синхронизации с upstream или продолжении выполнения Actions после получения изменённого workflow. Частные репозитории особенно опасны: в них чаще хранятся рабочие ключи, а полный Git-история позволяет извлекать данные, которые владельцы давно удалили из актуальных файлов.
Workflow возвращает атакующим идентификатор репозитория даже в том случае, если секреты не найдены. Так злоумышленники проверяют доступность среды выполнения и формируют карту пригодных для запуска репозиториев. Такой механизм даёт им отдельный перечень активных и доступных окружений: репозиторий может оказаться полезным как вычислительная площадка или точка дальнейшего проникновения, даже если в нём нет подходящих ключей. Кража учетных данных здесь совмещена с разведкой GitHub-инфраструктуры.
30 августа 2026 года был зафиксирован ещё один сценарий использования доступа. В репозитории kuafuai/DevOpsGPT атакующие изменили проект и встроили майнер XMRig в Docker-образ. XMRig часто применяют для добычи криптовалют, включая ориентированный на приватность Monero. При этом на момент публикации исследователи не обнаружили вредоносных релизов пакетов, опубликованных с помощью украденных учетных данных. Сам факт отсутствия таких релизов не отменяет необходимости проверять npm, PyPI, DockerHub и другие реестры.
Искать подозрительные workflow следует начиная с 31 августа 2026 года. Наличие security-audit.yml или github_actions_security.yml нужно рассматривать как возможный признак компрометации. Сначала следует отозвать токен или другую учетную запись GitHub, затем заменить все потенциально доступные облачные ключи, токены реестров, API-ключи, CI/CD-секреты, SSH-ключи, пароли баз данных и токены коммуникационных сервисов. Вредоносный файл требуется удалить из ветки по умолчанию, остальных веток, тегов и других ссылок репозитория.
Проверка должна охватывать публичные и частные форки, зеркала и синхронизированные копии, прежде всего 279 форков в пространстве henrywoo. В истории Git нужно искать старые ключи, потому что fetch-depth: 0 открывает workflow полный набор коммитов. В журналах GitHub Actions стоит проверить неожиданные запуски, исходящие соединения и команды curl. Отдельно следует осмотреть Docker-образы и конфигурации сборки на наличие посторонних изменений, включая XMRig, а также сверить историю публикаций пакетов и контейнеров с журналами владельцев.
