GitSpawn запускает код через Git в Claude Code

Исследователи Manifold нашли одну и ту же схему как минимум в пяти CLI-агентах для кода: Claude Code, Goose, Grok Build, Hermes и Qwen Code. В каждом из них служебные вызовы git выполняют команду, которую прописал сам репозиторий. Происходит это ещё до запроса на одобрение. Разбор под названием GitSpawn Manifold опубликовала 1 сентября. Авторы оговариваются, что уязвимых агентов нашли больше, чем назвали.

Началось всё с вопроса, что агент делает при запуске. Выяснилось, что агенты сначала собирают контекст проекта и почти всё берут из git. Часть вызовов идёт на старте, часть уже по ходу сессии. Агенту нужны текущая ветка, изменённые и проиндексированные файлы, файлы, которые затронула правка, список всех отслеживаемых путей или новый worktree для субагента. В качестве примеров Manifold приводит два вызова из разных продуктов, git status --porcelain=2 --branch и git diff --name-only HEAD. Обе команды самые обычные, и обе перед работой обновляют индекс.

На этом обновлении всё и держится. Настройка core.fsmonitor ускоряет git в больших репозиториях: git не обходит все файлы на диске, а спрашивает у внешней программы, что изменилось, и запускает её как раз при обновлении индекса. Поведение документированное и штатное. Но читается настройка из .git/config самого репозитория, поэтому достаточно строки fsmonitor = <command> в секции [core], и команду запустит любой git-вызов, который обновляет индекс. Какой именно вызов выбрал агент, роли не играет. К тому же core.fsmonitor не единственный такой ключ, и одна из находок Manifold с ним вообще не связана. В бюллетене GitHub по Copilot CLI насчитали больше 15 ключей, через которые git выполняет команды при status, diff или rev-parse, среди них core.hookspath, diff.external и merge.tool. Там же описан родственный случай: вредоносный bare-репозиторий (без рабочей копии), вложенный в проект, давал выполнение кода в версиях Copilot CLI до 1.0.42. Так что для авторов агентов класс проблемы уже не новый.

Принести такой конфиг через git нельзя. Клонирование, fetch и pull его не переносят, так что вредный URL ничего не сделает. Репозиторий должен попасть на машину файлами, вместе с готовой папкой .git: архивом, через общий диск, папку синхронизации или флешку. Так проекты передают коллеги друг другу, а консультанты клиентам. Все свои proof of concept исследователи доставляли в .zip.

Дальше команда работает от имени пользователя, с его правами и на его машине. Подпроцесс git запускает код самого агента, поэтому песочница и запросы одобрения его не перехватывают. «Модель разрешений этого вообще не видит», - пишут в Manifold.

Конкретнее всего задокументирован случай с Goose: CVE-2026-72718 опубликована 10 августа, по CVSS v4.0 она получила 7 баллов (High). До версии 1.44.0 команда goose review собирала изменения через git diff HEAD и git diff --name-only HEAD, не очищая конфигурацию репозитория. Команда злоумышленника срабатывала до обращения к модели, без отправленного промпта, одобрения инструмента и запроса доверия. Через неё можно читать и менять файлы, а также вытащить секреты из окружения, включая API-ключи провайдеров. Корень проблемы SentinelOne видит в том, что goose запускал git без переопределений вроде -c core.fsmonitor=false и без урезанного окружения. Исправление в 1.44.0 перевело эти вызовы на защищённый хелпер git_command().