Хакеры атаковали 8000 репозиториев GitHub ради ключей OpenAI, Anthropic и облачных сервисов

С 10 по 12 ноября 2026 года неизвестные злоумышленники провели масштабную кампанию по краже учётных данных из открытых репозиториев GitHub. Вредоносные коммиты появились в 8093 репозиториях, для их размещения использовались 4833 скомпрометированных аккаунта. Кампания, которую исследователи назвали wfxloot, целилась не только в исходный код, но и в секреты GitHub Actions, облачные учётные данные AWS, Azure и Google Cloud, а также ключи API ИИ-сервисов: OpenAI, Anthropic, Hugging Face, Gemini, Cursor и GitHub Copilot. По данным Aikido Security, злоумышленники создали 61 879 запросов на слияние в 61 734 репозиториях, замаскировав их под аудит зависимостей, и подтвердили кражу секретов более чем у 1800 целей. Главный инструмент атаки — shell-скрипт примерно на 1500 строк: он собирал токены, ключи и конфигурации, а затем отправлял данные на серверы злоумышленников или в Telegram. Характерная черта кампании — быстрая зачистка следов: заражённые изменения откатывались менее чем за минуту.

Хронология и масштаб кампании

По данным Aikido Security, кампания wfxloot началась 10 ноября 2026 года. Атакующие использовали 4833 взломанных аккаунта GitHub, чтобы проверить права на запись в 61 734 репозиториях. Для этого они открывали запросы на слияние с названием «docs: dependency audit notes» и веткой wfx-docs, добавляя небольшой файл с заметками. Так проверялось, позволяет ли украденная учётная запись вносить изменения в чужой проект. Около 91–92% таких запросов на момент анализа оставались открытыми, то есть владельцы проектов попросту не заметили активности. В 1343 репозиториях вредоносные коммиты публиковались от имени пользователей, отличных от владельцев, включая соавторов и ботов.

Три способа внедрения вредоносного кода

После проверки доступа злоумышленники внедряли вредоносный код одним из трёх способов. Из 8093 затронутых репозиториев в 7309 менялись существующие сценарии автоматической сборки, в 16 добавлялись новые рабочие процессы GitHub Actions, ещё в 771 — вредоносный скрипт, срабатывающий при установке npm-пакета через механизм postinstall. Последний вариант особенно опасен: код мог выполняться не только на сервере, но и на компьютере разработчика при установке заражённого пакета.

Что собирал скрипт на 1500 строк

Основной инструмент атаки — shell-скрипт объёмом около 1500 строк. Он собирал:

• данные GitHub Actions и переменные, GITHUB_TOKEN, токены OIDC и токены среды выполнения;
• учётные данные облаков AWS, Azure и Google Cloud, в том числе через метаданные self-hosted раннеров;
• ключи разработчика: Git, SSH, GPG, Docker, Kubernetes, npm, PyPI, Vault, Terraform;
• ключи ИИ-сервисов и инструментов: OpenAI, Anthropic, Gemini, Hugging Face, Cursor, GitHub Copilot;
• переменные окружения, .env-файлы, закрытые ключи, историю командной оболочки и память процессов.

Собранные данные упаковывались в tar-архивы и отправлялись по HTTP POST на серверы злоумышленников или в Telegram. Скрипт также пробовал повысить привилегии в облаке: в AWS он создавал новые ключи доступа и менял политики доверия ролей, в Azure добавлял учётные данные в регистрации приложений Entra ID, а также пытался добраться до Google Cloud, HashiCorp Vault и Kubernetes.

Выход за пределы GitHub

Кампания затронула и цепочку поставки ПО за пределами GitHub. Вредоносный код нашли в пакетах и модулях:

Не все заражённые версии запускали вредоносный код при обычной установке: в gocurl для срабатывания требовался определённый тег версии, а скрипт redock выполнялся только при изменениях ветки beta. Отдельно вредоносные изменения обнаружили в 28 репозиториях WebdriverIO, где коммиты публиковались от имени бота wdio-bot.

Кто пострадал и что делать

Среди взломанных аккаунтов оказались организации из списка Fortune 100, Управление общих служб США, правительство Франции, Nextcloud и WebdriverIO. Около 50 аккаунтов имели права на публикацию пакетов в npm, PyPI, Go, crates и Packagist. Исследователи также нашли совпадения с кампанией GhostAction 2025 года.

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

Источники: ixbt.com, habr.com, aikido.dev