Кампания FakeGit за 34 часа активировала 17 610 вредоносных репозиториев GitHub, а пиковая скорость публикаций достигала 2 999 в час. Для российских разработчиков, команд DevOps и компаний, которые ищут библиотеки, AI-навыки и MCP-серверы в открытых каталогах, это неприятное напоминание: привычный README на GitHub всё чаще становится не документацией, а посадочной страницей для вредоносного загрузчика.
О новой волне сообщает BleepingComputer со ссылкой на исследователей платформы защиты цепочек поставки Apiiro. Репозитории предлагают убедительно оформленные инструкции установки и кнопку скачивания, ведущую на ZIP-архив. Внутри находится SmartLoader — начальная программа-загрузчик, способная подтянуть на устройство другие вредоносные компоненты. В начале октября та же инфраструктура использовалась для распространения инфостилера StealC, который ориентирован на кражу данных с заражённых систем.
Особенно тревожна не только масса приманок, но и способ их запуска. По данным Apiiro, операторы не создавали десятки тысяч проектов в момент атаки: репозитории уже существовали и были быстро перенастроены на новые архивы. Среди изученных коммитов 97% меняли только README-файлы, а 88% добавляли ссылку на ZIP с SmartLoader. То есть атака выглядит как обычное обновление описания проекта — и почти не оставляет сигнала тем, кто привык оценивать репозиторий по свежести коммитов.
FakeGit действует не первый месяц. В июле исследователи корпоративной браузерной платформы Island описали около 7 600 поддельных проектов, продвигавших SmartLoader. Примерно 800 из них маскировались под AI-навыки или MCP-серверы и попадали в публичные реестры и каталоги. Эта деталь важна для команд, которые внедряют ИИ-инструменты: спрос на готовые интеграции создаёт идеальную среду для атаки, где название проекта звучит достаточно правдоподобно, а проверка автора остаётся необязательным шагом.
Почему удаление репозиториев не решает проблему
Заблокировать одну ссылку или удалить один ZIP-файл в этой схеме недостаточно. Apiiro обнаружила вредоносные архивы в форках, старых версиях файлов, активах релизов, вложениях к задачам и отдельных репозиториях, используемых только как файловое хранилище. Если один адрес перестаёт работать, злоумышленник меняет ссылку в README на запасную копию. Сам проект при этом остаётся на месте и продолжает собирать переходы из поиска, каталогов и чужих инструкций.
Списки угроз тоже покрывают кампанию лишь частично. По оценке Apiiro, 71% инфраструктуры FakeGit отсутствовал в URLhaus до публикации отчёта. DNS-блокировки здесь ограниченно полезны: нельзя заблокировать отдельный файл на GitHub через доменный список, не отрезав сотрудникам доступ ко всему сервису. Для бизнеса это типичная проблема защиты цепочки поставки: вредоносный контент использует легитимную и критичную для разработки платформу, поэтому грубая блокировка ломает процессы, а точечная требует постоянного мониторинга.
Отдельный риск связан с аккаунтами. Большинство проектов создаётся через одноразовые учётные записи, но исследователи нашли не менее 700 аккаунтов, похожих на профили реальных разработчиков. Неясно, все ли они были скомпрометированы, однако сам масштаб делает простую эвристику «старый аккаунт — значит безопасно» ненадёжной. Проверять нужно не только возраст профиля, но и историю репозитория, реальную активность владельца, состав коммитов, обсуждения, релизы и совпадение ссылок с официальными каналами проекта.
Что стоит изменить в практике команд
Для инженеров базовое правило выглядит скучно, но работает: не запускать архивы, предложенные README, если их происхождение нельзя подтвердить через официальный сайт вендора, официальный реестр или репозиторий разработчика. Особенно это касается расширений для IDE, AI-навыков, MCP-серверов и утилит, которые обещают быстро подключить API. Внутренние гайды по использованию open source полезно дополнить простым требованием: внешние зависимости и инструменты скачиваются из подтверждённых источников, а ссылки из поисковой выдачи и каталогов считаются лишь поводом для проверки, не источником доверия.
Если SmartLoader уже запускался на рабочей машине, Apiiro советует рассматривать инцидент как возможную компрометацию аккаунта GitHub: отозвать активные сессии и токены доступа, затем перейти на ключи доступа. Практически это также повод проверить токены, используемые в CI/CD, доступы к приватным репозиториям и секреты, доступные локальной среде разработки. Загрузчик опасен именно тем, что его конечная нагрузка может меняться: сегодня приманка ведёт к одному семейству вредоносного ПО, завтра — к другому.
FakeGit показывает, как меняется фишинг для разработчиков: вместо письма с подозрительным вложением приходит аккуратный проект с инструкцией, знакомой лицензией и ссылкой на «готовую сборку». Чем больше команды полагаются на открытые каталоги для ускорения разработки, тем ценнее становится не скорость установки, а воспроизводимая проверка происхождения. Подробнее о механике кампании и выводах исследователей можно прочитать у .