GhostAction: взломано 1900 аккаунтов GitHub, как защититься

В октябре 2026 года исследователи описали кампанию GhostAction: злоумышленники захватили около 1900 аккаунтов GitHub и пытались украсть секреты более чем из 30 000 репозиториев. Атака строилась на украденных токенах доступа и вредоносных файлах автоматизации. Если ваш код и сборка живут на GitHub, стоит проверить несколько вещей.

Что произошло

По данным GitGuardian, всплеск активности пришёлся на 8–9 октября. Злоумышленники использовали украденные персональные токены доступа и учётные данные из баз вредоносного ПО, чтобы получить доступ к репозиториям. Затем они добавляли вредоносный файл автоматизации GitHub Actions под безобидным названием вроде «security-audit.yml», который пытался выгрузить секреты из сборки.

GitHub начал блокировать вредоносный файл 9 октября, поэтому поздние волны уже не могли выгрузить секреты. Часть жертв пострадала и в прошлых волнах — признак того, что украденные секреты так и не сменили.

Кого касается

Всех, чей код, сборка и выкладка завязаны на GitHub, особенно если в репозиториях или в настройках сборки хранятся секреты: ключи облаков, токены реестров пакетов, ключи ИИ-сервисов. Именно за ними охотилась кампания.

Отдельный риск — повторные жертвы. Если секрет когда-то утёк и его не сменили, он остаётся рабочим ключом для новой атаки. GhostAction этим и пользовался.

Что делать

1. Проверьте файлы автоматизации в репозиториях на незнакомые имена вроде «security-audit.yml» или «github_actions_security.yml», которые вы не добавляли.
2. Смените секреты, которые могли утечь: ключи облаков, токены реестров, ключи ИИ-сервисов. Особенно те, что не менялись давно.
3. Перейдите на безопасную публикацию без долгоживущих токенов, где это возможно (доверенные издатели через OIDC).
4. Включите двухфакторную аутентификацию на всех аккаунтах с доступом к репозиториям.
5. Проверьте активные токены и отзовите неиспользуемые.
6. Настройте оповещение о новых файлах автоматизации и необычных действиях в репозиториях.

Наше мнение

GhostAction показывает, что репозиторий кода — это не просто хранилище, а ценная цель: в нём и код, и секреты, и доступ к сборке и выкладке. Защищать его нужно так же серьёзно, как боевой сервер.

Два вывода мы считаем главными. Первый: секреты нельзя хранить в репозитории, даже приватном, и тем более нельзя оставлять утёкшие секреты рабочими — их нужно сразу менять. Второй: долгоживущие токены — это мина, и переход на безопасную публикацию через временные учётные данные закрывает целый класс атак. Для команды это разовая работа по настройке, которая окупается первой же предотвращённой утечкой.

Почему несменённые секреты — главная проблема

Самая показательная деталь GhostAction — повторные жертвы. Компании, которые пострадали и раньше, снова попались, потому что украденные секреты так и остались рабочими. Это типичная ошибка: после инцидента закрывают дыру, но забывают сменить всё, что могло утечь. А украденный ключ не «протухает» сам — он работает, пока его не отзовут. Поэтому после любого подозрения на утечку правило простое: сменить все секреты, которые могли быть затронуты, и не полагаться на то, что злоумышленник ими не воспользуется.

Как уменьшить ценность украденного секрета

Помимо смены, есть способы заранее снизить ущерб от утечки токена. Короткий срок жизни: токен, который действует часы, а не месяцы, почти бесполезен после кражи. Минимальные права: токен для одной задачи не должен открывать доступ ко всему. Привязка к условиям: некоторые токены можно ограничить по источнику или окружению. Чем меньше возможностей у украденного ключа, тем спокойнее можно пережить его утечку. Безопасная публикация через временные учётные данные доводит эту идею до логического конца — долгоживущего секрета, который можно украсть, просто нет.

Репозиторий как цель, а не как склад

Главная смена мышления, к которой подталкивает GhostAction, — перестать воспринимать репозиторий как безопасный склад. В нём концентрируется слишком многое: код, история, настройки сборки, нередко секреты. Для злоумышленника это одна точка, через которую можно добраться и до инфраструктуры, и до выкладки продукта. Поэтому защита репозитория заслуживает тех же мер, что и боевой сервер: строгий контроль доступа, двухфакторная аутентификация обязательна для всех, регулярная ревизия токенов и прав, отдельное хранилище для секретов вместо их размещения в коде. Удобство общего доступа «чтобы всем было проще» здесь оборачивается риском, которым мало кто управляет.

Стоит помнить и про сторонние действия в репозитории: интеграции, боты, приложения GitHub с доступом к коду. Каждое из них — ещё один путь внутрь, и их список тоже нужно пересматривать. Разовая ревизия доступа к репозиториям — кто из людей, какие токены, какие приложения — часто вскрывает забытые права, которые давно пора отозвать.

Практичный первый шаг — вынести секреты из репозиториев. Специальные хранилища секретов и механизм переменных окружения решают эту задачу, а автоматические сканеры находят случайно закоммиченные ключи. После этого стоит пройтись по токенам: сократить их срок жизни, ограничить права и отозвать всё, чем давно не пользуются.