Код, интерфейсы и трафик без воды
lawebbox

Обнаружен новый способ внедрения вредоносных репозиториев в GitHub

По данным блога Orchid Files, на GitHub всплыла массовая схема раздачи троянов под видом легитимных репозиториев — из ~40 тысяч кандидатов под раздачу попадает порядка десяти тысяч.

Максим Воронцов, Хардкорный бэкендер и девопс · обновлено 02 августа 2026 г.

Обнаружен новый способ внедрения вредоносных репозиториев в GitHub

Для бэкенда и девопса это не абстрактная новость: любой npm install, клон по совету из README или pipeline, подтягивающий «последнюю версию», автоматически становится точкой входа.

Что устроено

Схема простая до отвращения. Берётся свежий репозиторий, форкается целиком — с коммитами и списком контрибьюторов. Затем в README подсаживается ссылка на zip, замаскированный под «установщик». Каждые несколько часов крайний коммит сносится и пересоздаётся с тем же заголовком Update README.md — это, судя по всему, обход автопроверок платформы.

Внутри архива — четыре файла, в числе которых loader.exe или luajit.exe плюс lua51.dll. В связке это троян. На забавный нюанс обратили внимание исследователи: сама ссылка на VirusTotal выглядит чисто, флаг всплывает только при распаковке содержимого. То есть антивирь на шлюзе, проверяющий URL до загрузки тела, дружно идёт мимо кассы.

Почему «зрелый» репозиторий больше не аргумент

Привычные маркеры доверия — история коммитов, пачка контрибьюторов, осмысленный README — в этой схеме подделываются тривиально. Это даже не требует отдельного скрипта: обычный поиск по GitHub с фильтром по характерным заголовкам README и упоминанию zip сразу выдаёт пачку похожих репозиториев, в том числе обновлённых полчаса назад.

После публикации исследования GitHub снёс все десять тысяч из обнаруженного списка. История на этом не закончилась — повторный прогон скрипта показал, что аналогичные репозитории по той же схеме оставались на месте. Удаление реактивное, а не проактивное.

Что делать на проде

Пока модерация платформы работает в режиме «пришли ссылку — зачистим», ответственность падает на инженера. Минимум, что требуется прямо сейчас:

  • Не качать zip-«установщики» из README, даже если репозиторий выглядит взрослым. Исходники принято ставить из пакетного менеджера, а не из приатаченного архива.
  • В package.json / requirements.txt / go.mod фиксировать конкретные версии и хеши, а не ветки вроде main от чужих репо. Любой `npm install со ссылкой «поставь отсюда» — повод остановиться.
  • В CI запретить выполнение скачанных бинарников и архивов из репозиториев как часть шага сборки. Бинарь — артефакт, он не должен приходить из сорсов.
  • Прогонять распакованное содержимое через статический анализ (VirusTotal, песочница) до того, как оно попадёт в pipeline. Проверки URL на саму ссылку уже недостаточно.
  • Переписать внутренние доки: «склонируйте этот репозиторий и запустите install.sh» — больше не инструкция, это тикет на инцидент.

И да: бэкапы. Если кто-то из команды всё-таки дёрнул «правильный» zip и запустил его под рутом — у вас должна быть точка отката, не зависящая от этого хоста.