Для кого: людей и организаций, которые разрабатывают или администрируют репозитории на GitHub, а также всех, кто использует GitHub Actions или облачные учётные данные (включая федерацию OIDC). Статья основана на публичных публикациях исследовавших компаний по информационной безопасности и на уведомлении связанного провайдера. Шаги атаки здесь не описываются.
続報待ち：この記事は公式発表に合わせて更新します
- Кого это касается
людей и организаций, которые разрабатывают или администрируют репозитории на GitHub, а также всех, кто использует GitHub Actions или облачные учётные данные (включая федерацию OIDC).
- ПодтвержденоСмотреть таблицу ↓
- Около 4 800 аккаунтов использованы
- Пробные pull request в 61 764 репозитория
- Репозитории с вредоносными изменениями
Ещё 3
- Вредоносный код выполнился и учётные данные ушли
- Кража секретов и облачных учётных данных
- Заражение опубликованных пакетов
Названо как возможно затронутое
- Закрепление в облаке (настройки, переживающие смену секретов)
- Пока не подтверждено
- Окончательное число затронутых аккаунтов и репозиториев (исследовавшие компании считают по-разному)
- Как токены были украдены изначально (для кампании в целом не установлено, кроме случая облачного провайдера)
- Официальное заявление GitHub (не указано на момент проверки 14 ноября)
Ещё 2
- Связь с отдельной октябрьской кампанией того же актора (компании A и C не утверждают, что актор один)
- Завершение отзыва токенов у облачного провайдера (провайдер добавил, что процесс остановился на полпути)
- Что сделать сейчасСмотреть шаги ↓
- Проверьте незнакомые pull request, ветки и запуски Actions
- Отзовите токены, авторизации и сессии скомпрометированного аккаунта
- Если вредоносные изменения могли выполниться, смените все секреты и облачные права, которые мог прочитать этот репозиторий
Ещё 3
- Проверьте облачную сторону на изменения, переживающие смену секретов
- Составьте список токенов и сторонних приложений
- Проверьте, что ваши приложения не открывают папку системы контроля версий
- Где проверить (источник)Все источники ↓
- GitHub, «Changelog» и «Security» (официальный блог и журнал изменений; записи об этом нет; проверено 14 ноября)
- Последняя проверка
- по состоянию на 14 ноября 2026 года
Планы обновлений и что мы проверили
Публикации исследовавших компаний вышли 12 ноября и могут быть исправлены. На 14 ноября в блоге GitHub, журнале изменений и истории статуса не было записей об этом.
Что владельцам репозиториев и разработчикам нужно сделать сегодня
Проверьте незнакомые pull request, ветки и запуски Actions
В каждом репозитории, в который может писать ваш аккаунт (включая организации, где вы соавтор), проверьте три вещи с 10 ноября. По данным компании A, из 61 839 пробных pull request 10 431 ушёл в репозитории, которыми аккаунт не владеет, через доступ соавтора или организации.
- Pull request, которые не открывали ни вы, ни коллеги. Даже если название выглядит безобидно (например, обновление документации), один и тот же шаблон во многих репозиториях — тревожный признак
- Незнакомые недолговечные ветки или следы того, что ветки создавали и удаляли
- История запусков Actions с незнакомыми запусками или пропусками в номерах запусков. Компании A и C пишут, что атакующий удаляет запуски и журналы примерно за минуту, поэтому пропуск в нумерации — подсказка. Проверьте также журнал аудита организации
Если вы что-то нашли, продолжайте ниже. Компания A пишет, что аккаунт с пробным pull request нужно считать скомпрометированным, даже если следующий этап не выполнялся.
Отзовите токены, авторизации и сессии скомпрометированного аккаунта
Этот порядок соответствует рекомендациям компаний B и C.
- Отзовите личные токены доступа, авторизации сторонних приложений (OAuth-приложений и GitHub-приложений), SSH-ключи и активные сессии, затем создайте заново только необходимое
- Включите двухэтапную проверку. Уже украденный токен работает и без неё, поэтому сначала отзывают токен (мнение этого сайта)
- Закройте пробный pull request и удалите незнакомые ветки. Перед удалением запишите, от имени какого аккаунта они созданы
Если вредоносные изменения могли выполниться, смените все секреты и облачные права, которые мог прочитать этот репозиторий
Компании A и B пишут, что если вредоносное изменение выполнилось, все секреты и облачные роли, доступные этому рабочему процессу, нужно считать украденными.
- Перевыпустите секреты и переменные Actions (на уровне репозитория, среды и организации), токены публикации (включая токены для пакетов) и ключи развёртывания и аннулируйте старые
- Если вы заходите в облачный аккаунт через OIDC, включите и это облачное право (следующий шаг)
- Если вы собирали репозиторий, который мог получить вредоносное изменение, на машине разработчика, смените и учётные данные, которые эта машина могла прочитать (SSH-ключи, облачные учётные данные, токены публикации пакетов и т. д.). Компании B и C сообщают об изменениях, которые срабатывают при установке пакета
- Если вы публиковали пакеты после 10 ноября, проверьте, что опубликованные версии не содержат вредоносного изменения; если содержат, отзовите их и опубликуйте заново из чистого состояния
Проверьте облачную сторону на изменения, переживающие смену секретов
В качестве изменений, которые переживают смену секретов, компания A называет переписывание политики доверия роли AWS и добавление федеративных учётных данных Azure (компания B упоминает и оставленные ключи доступа AWS). Проверьте эти две области и в журналах аудита, и в текущих настройках.
- AWS: вновь созданные ключи доступа и изменения политик доверия ролей (не расширилось ли доверие на непредусмотренные аккаунты или условия)
- Azure (Entra ID): федеративные учётные данные, добавленные приложениям и указывающие обратно на репозиторий
Отдельно, для проверки повышения привилегий с украденными учётными данными, посмотрите также Google Cloud (необычное использование сервисных аккаунтов или вызовы выпуска токенов) и Vault или Kubernetes (незнакомые входы через GitHub OIDC).
Даже если вы ничего не нашли, проверьте, сужены ли условия доверия OIDC до репозитория, ветки и среды (см. «Что пересмотреть» ниже).
Составьте список токенов и сторонних приложений
В настройках GitHub перечислите следующее и удалите лишнее и незнакомое.
- Личные токены доступа: удалите неиспользуемые; для остальных ограничьте репозитории, права и срок действия
- OAuth-приложения и GitHub-приложения, которым вы дали авторизацию, включая подключённые для хостинга или развёртывания CI. Снимите авторизацию у тех, которыми больше не пользуетесь
- SSH-ключи и ключи развёртывания: удалите неиспользуемые и без владельца
- Права ботов и аккаунтов автоматизации: проверьте, нет ли среди них тех, что могут обходить правила защищённых веток
Согласно уведомлению облачного провайдера, приложение этого провайдера требует повторного подключения. Если вы им пользуетесь, следуйте инструкциям провайдера.
Проверьте, что ваши приложения не открывают папку системы контроля версий
Тот же провайдер объясняет, что некоторые приложения, развёрнутые через GitHub, публиковали весь каталог сборки, поэтому оставленный там токен можно было получить. Проверьте, что публичный URL вашего приложения не отдаёт содержимое папки системы контроля версий (.git). Если отдаёт, исключите её из образа, разверните заново и смените учётные данные, которые в ней были. Проверьте также, не использует ли ваша платформа развёртывания похожий механизм.
Что произошло (по исследовавшим компаниям и связанному провайдеру)
Далее изложено по публичным публикациям компаний по информационной безопасности A, B и C (все опубликованы 12 ноября 2026 года) и уведомлению одного облачного провайдера (узнал вечером 12 ноября, дополнение 13 ноября). Это собственные рассказы сторон и исследователей, GitHub их не подтверждал. Время — UTC, если не указано иное.
10 нояб., около 12:45
По данным компании A, атакующий начал действовать с украденными токенами в репозиториях, в которые каждый токен мог писать. В каждом репозитории он сначала отправлял пробный pull request, затем вносил вредоносное изменение, примерно через минуту откатывал его и удалял запуск и журналы. Компания B тоже относит первое вредоносное изменение к 12:46.11 нояб., 15:00
Конец периода для 61 839 пробных pull request, подсчитанных компанией A.12 нояб., 04:36
Конец периода для 8 093 публичных репозиториев с вредоносными изменениями, подсчитанных компанией B.12 нояб., 07:40
Время, на которое компания C насчитала более 63 000 пробных pull request. Компании A, B и C опубликовали свои материалы в тот же день.12 нояб., 22:00 (часовой пояс не указан)
Один облачный провайдер опубликовал уведомление: он узнал (12 ноября, время не указано), что токены, выпущенные для его GitHub-приложения, использовались посторонними в репозиториях клиентов (уведомление провайдера).13 нояб., 15:54
Провайдер добавил, что отзыв всех пользовательских токенов остановился на полпути и что GitHub проводит расследование (уведомление провайдера).
Действующий украденный токен
Пробный pull request проверяет, можно ли писать
↓→
Вредоносное изменение
Собирает секреты CI и облачные учётные данные и отправляет наружу
↓→
Заметание следов
Откатывает изменение, удаляет запуски и журналы; настройки могут остаться в облаке
Цифры по источникам (не складывайте)
| Источник (роль) | Что считали | Цифра | Примечание |
|---|---|---|---|
| Компания A (первой сообщила) | Аккаунты, отправившие / репозитории, получившие пробные pull request | 4 837 аккаунтов / 61 764 репозитория | Около 92% всё ещё открыты (знаменатель — 10 431 PR, отправленный в репозитории, которыми аккаунт не владеет) |
| Компания A | Репозитории, где вредоносный код выполнился и учётные данные ушли | Не менее 1 835 (в другом месте 1 806) | Две цифры в одной публикации; говорит, что число может быть нижней границей |
| Компания A | Аккаунты, которые могут публиковать пакеты | Не менее 50 | Права публикации в npm, Go, PyPI, Packagist и crates в её понимании |
| Компания B | Публичные репозитории с вредоносными изменениями (10 нояб., 12:46 – 12 нояб., 04:36) | 8 093 | Не число случаев выполнения. Разбивка в сумме даёт 8096; расхождение не объяснено |
| Компания B | Пробные pull request | 61 879 PR / 4 833 аккаунта / 61 734 репозитория | Не входят в 8 093 |
| Компания C | Пробные pull request (на 12 нояб., 07:40) | Более 63 000 | Около 90% открыты. 173 из них (19 аккаунтов) пришли через токены, выпущенные для GitHub-приложения одного облачного провайдера |
| Облачный провайдер (собственное уведомление) | Пробные pull request, найденные в аккаунтах затронутых клиентов | Более 250 | Говорит, что затронуто небольшое число клиентов |
Компания B пишет, что её цифры получены из поиска GitHub, который охватывает только ветки по умолчанию публичных репозиториев, поэтому реальный итог, вероятно, выше.
- Что похищено
- Секреты и переменные GitHub Actions, токены рабочих процессов, облачные учётные данные (AWS, Azure, Google Cloud), учётные данные разработчиков и ИИ-сервисов (компания A)
- Причина (рассказ исследователей)
- Использование действующих украденных токенов, а не уязвимость GitHub Actions (компания C). Коммиты появляются под настоящими именами пользователей и без подписи, что указывает на украденные токены (вывод компании B)
- Как получены токены
- Для кампании в целом не установлено. Для части, прошедшей через приложение облачного провайдера, компания C тоже говорит, что не смогла установить, как получены токены, и свидетельств взлома инфраструктуры провайдера нет
- Рассказ облачного провайдера
- Его инфраструктура не взломана. При развёртывании через GitHub токен остался в файле конфигурации в каталоге сборки, а некоторые приложения публиковали весь каталог, поэтому его можно было получить. Затронуто небольшое число клиентов, с ними связались индивидуально. Провайдер начал отзывать все пользовательские токены, выпущенные для приложения, и изменил процесс развёртывания. Он говорит, что развёртывания через его инструмент командной строки, его API-токены и работающие приложения не затронуты
- Влияние на пакеты
- Компания B изучила 218 пакетов npm, Go и Packagist, исходные репозитории которых получили вредоносные изменения. Вредоносные версии были в трёх пакетах (один Packagist, два Go), всего пять версий в её списке; других она не нашла. PyPI и другие не проверялись. Компания A тоже считает целью атакующего секреты CI, а заражение пакетов — побочным эффектом автоматической публикации
- Связь с отдельной октябрьской кампанией
- Компания A говорит, что аккаунты, пострадавшие в октябрьской кампании, чаще попадали и в эту, но оценивает их как отдельные операции разных акторов. Компания C тоже говорит, что совпадение не доказывает единого актора (украденные токены передают и продают)
- Официальное заявление GitHub
- Не указано (блог, журнал изменений и история статуса проверены 14 ноября 2026 года)
Что известно и что нет
Состояние на 14 ноября 2026 года. Когда будут новости, мы обновим столбец статуса.
| Пункт | Что опубликовано | Статус |
|---|---|---|
| Около 4 800 аккаунтов использованы | Действующие украденные токены применены для отправки пробных pull request | Подтверждено (компании A и B) |
| Пробные pull request в 61 764 репозитория | Число отличается от числа случаев, где последовало изменение | Подтверждено (компания A; компания B насчитала 61 734) |
| Репозитории с вредоносными изменениями | 8 093 публичных репозитория | Подтверждено (компания B; только публичные репозитории и ветки по умолчанию) |
| Вредоносный код выполнился и учётные данные ушли | Не менее 1 835 репозиториев | Подтверждено (компания A; называет и 1 806) |
| Кража секретов и облачных учётных данных | В репозиториях, где код выполнился | Подтверждено (компании A и B) |
| Закрепление в облаке (настройки, переживающие смену секретов) | Переписывание политики доверия роли AWS и добавление федеративных учётных данных Azure (компания A); компания B упоминает и оставленные ключи доступа AWS | Возможно (компании A и B) |
| Использование уязвимости GitHub Actions | Не использовалась | Не входит (компания C) |
| Заражение опубликованных пакетов | Три пакета (один Packagist, два Go), всего пять версий (других не нашли) | Подтверждено (компания B; PyPI и другие не проверялись) |
| Взлом инфраструктуры облачного провайдера | Свидетельств нет (компания C); провайдер отрицает взлом | Не подтверждено (компания C, провайдер) |
| Как токены были украдены изначально | Объяснено для части токенов приложения облачного провайдера; в целом неизвестно | Расследуется |
| Связь с отдельной октябрьской кампанией | Компания A видит отдельные операции; компания C не утверждает | Расследуется |
| Официальное заявление GitHub | Не найдено | Не указано |
| Подтверждённый список затронутых организаций | Не опубликован | Не указано |
Как читать: цифры считают разное и за два дня менялись
1 835 у компании A — это оценка запусков, 8 093 у компании B — публичные репозитории с вредоносными изменениями, а 63 000 у компании C — пробные pull request. Это не одно и то же. У многих репозиториев, получивших только пробный pull request, изменений и кражи могло не быть. Однако, по данным компании A, аккаунт, отправивший пробный pull request, нужно считать скомпрометированным, даже если изменение не последовало.
Что может произойти при использовании действующих украденных токенов
Ниже — общее описание, оно не означает, что здесь произошло именно это. О том, что, по сообщениям исследовавших компаний, произошло, написано выше в «Что произошло».
Если токен действующий, атакующий может писать как законный пользователь. Уязвимости функции GitHub, которую можно использовать, нет, и обновление программы этого не останавливает. Если аккаунт с правом записи может изменять рабочий процесс CI, под удар попадают вместе секреты и облачные права, которые этот рабочий процесс может прочитать. Если OIDC-доверие к облачному аккаунту слишком широкое (войти может любая ветка или рабочий процесс), временные учётные данные могут выдаваться и без сохранённого секрета. Если ваш аккаунт — соавтор в чужой организации, ущерб выходит за пределы того, чем вы владеете.
Что пересмотреть в CI и облачных правах
Этот раздел не оценка пострадавших. На основе отчётов исследователей он сосредоточен на том, что проверить в собственной среде, и это мнение этого сайта.
Не держите токены широкими и долгоживущими
Здесь использовались действующие украденные токены. Ограничьте личные токены доступа конкретными репозиториями и правами, задайте короткий срок действия и удаляйте неиспользуемые (используйте детализированный тип). Авторизуйте сторонние приложения только на нужный им объём (мнение этого сайта).
Сузьте права рабочих процессов и условия входа в облако
Сделайте права рабочих процессов по умолчанию только на чтение и давайте запись только там, где нужно. Сузьте облачное OIDC-доверие до репозитория, ветки и среды, чтобы войти мог не каждый рабочий процесс. Если у секретов среды есть утверждающие, переписанный рабочий процесс не сможет просто прочитать производственные секреты (мнение этого сайта).
Закрепите защиту веток обязательными ревью
Компания A пишет, что в коде есть механизм, предназначенный для обхода защиты веток. Не полагайтесь только на названия проверок: требуйте одобряющие ревью от владельцев кода и не делайте исключений для ботов (мнение этого сайта).
Обнаруживайте пропуски в номерах запусков и изменения облачных настроек
В этом случае запуски и журналы удалялись, и подсказкой стали пропуски в нумерации. Храните журнал аудита организации и настройте оповещения об изменениях рабочих процессов, а в облаке — о создании ключей доступа, изменении политик доверия и добавлении федерации идентичностей. Компания C также рекомендует ограничить исходящий трафик CI списком разрешённых адресов.
Не храните секреты в репозитории
Помимо секретов CI, учётные данные в истории кода уходят вместе с украденным токеном любого, кто может их читать. О том, как ловить их до коммита, см. Остановка секретов до коммита с gitleaks, а о порядке отзыва — 540 000 учётных данных, открытых на GitHub, всё ещё действуют.
Источники (публичные материалы)
Факты в этой статье взяты из публичной информации ниже. Официального заявления GitHub об этом нет (проверено 14 ноября). Подробности шагов атаки не описываются.
- GitHub, «Changelog» и «Security» (официальный блог и журнал изменений; записи об этом нет; проверено 14 ноября) — github.blog / github.blog
- GitHub Status (официальная история инцидентов; записи об этом нет; проверено 14 ноября) — githubstatus.com
- Уведомление одного облачного провайдера, «Security: GitHub tokens exposed by apps deployed from GitHub» (официальный форум сообщества; узнал 12 ноября, дополнение 13 ноября; проверено 14 ноября) — community.fly.io
- Компания A (компания по информационной безопасности; первой сообщила), «wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories» (12 ноября 2026; проверено 14 ноября) — aikido.dev
- Компания B (компания по информационной безопасности), «wfx: GitHub Actions Credential Stealer Hits 8,000 Repos» (12 ноября 2026; проверено 14 ноября) — safedep.io
- Компания C (компания по информационной безопасности), «WFX Phantom: The GitHub Actions Secret Stealer That Deletes Its Tracks» (12 ноября 2026; проверено 14 ноября) — stepsecurity.io
- Пресса: BleepingComputer, «Hackers compromise 4,800 GitHub accounts to steal cloud credentials» (проверено в ноябре; освещение публикации компании A) — bleepingcomputer.com
История обновлений
2026-11-14: первая версия. Основана на публичных публикациях трёх компаний по информационной безопасности (все от 12 ноября) и уведомлении одного облачного провайдера. Официального заявления GitHub нет. Если сообщения прессы расходятся, первичным источником считается оригинальная публикация каждой стороны. Мы обновим статью, когда появятся новые сведения.
Читайте далее
- Опубликованные учётные данные, которые остаются действующими, потому что их не отозвали: 540 000 учётных данных, открытых на GitHub, всё ещё действуют
- Ещё один случай, когда целью стала разработка на GitHub: Атака на цепочку поставок TanStack и Nx
- Порядок отзыва и ущерб через пакеты: Защита от атак на цепочку поставок npm
- Защита аккаунта: Двухэтапная проверка на GitHub / Основы переменных окружения и API-ключей
- Инциденты, которые происходят с законными учётными данными: Утечки 2026 года происходят с законными учётными данными
- Другие инциденты 2026 года: Утечки данных и кибератаки 2026 года