GitSpawn: открыл чужую папку в ИИ-агенте - и запустился чужой код

GitSpawn - это класс уязвимостей, при котором подготовленный репозиторий выполняет команду злоумышленника, стоит открыть его в ИИ-агенте вроде Claude Code, Cursor или Codex. Ничего не набираешь, ничего не подтверждаешь - код запускается в фоне при открытии папки. Защита простая: обнови агента и не открывай чужие папки, не заглянув в их .git/config.

Нашли проблему в Manifold Security и опубликовали разбор 1 сентября. Ниже - как безобидная команда git status превращается в чужой код на твоей машине, почему обычный git clone безопасен, а присланный архив нет, и что поставить между агентом и своими ключами.

Что такое GitSpawn

GitSpawn - это не одна дыра в конкретной программе, а общий приём против целого класса инструментов. Исследователь Manifold Security Франсиско Росалес разбирался, что именно делают консольные ИИ-агенты в момент старта, и заметил закономерность: почти каждый из них при открытии проекта тихо запускает git-команды, чтобы собрать контекст - какая ветка, какие файлы изменены. Обычная git status, обычная git diff.

Проблема в том, когда они это делают. На части агентов git запускается до того, как ты подтвердил доверие к папке, а на некоторых - вообще до авторизации. Агент открыл директорию - и уже потрогал её содержимое своими руками. А git, как выяснилось, слишком послушен к тому, что лежит внутри репозитория.

Как обычная команда запускает чужой код

У git есть настройки, которые он читает из файла .git/config внутри самого репозитория. Среди них - core.fsmonitor. Это оптимизация для больших проектов: вместо того чтобы каждый раз сканировать все файлы, git запускает указанную вспомогательную программу, и та сообщает, что изменилось. Ключевое слово - запускает программу. И запускает её при обновлении индекса, то есть на тех самых git status и git diff.

Дальше арифметика простая. Злоумышленник кладёт в .git/config вместо честного помощника свою команду. Ты открываешь папку в агенте. Агент в фоне зовёт git status, чтобы понять, где ты находишься. Git читает конфиг, видит core.fsmonitor и честно выполняет чужую команду - с твоими правами, вне песочницы агента, без единого запроса на подтверждение. По формулировке Manifold, это «выполнение произвольного кода от имени разработчика, снаружи песочницы, без запроса на подтверждение».

core.fsmonitor - не единственный такой «сток». Тем же способом работают core.hooksPath (подмена расположения git-хуков) и фильтры атрибутов. Ещё один рабочий ключ исследователи намеренно не назвали - он на момент публикации оставался непропатченным.

Дифф: слева - строка core.fsmonitor в .git/config с чужой командой, срабатывающей на git status; справа - тот же вызов, обёрнутый в git -c core.fsmonitor=false status

Почему git clone безопасен, а архив - нет

Хорошая новость: удалённо так не атакуют. Настройки из .git/config не путешествуют вместе с репозиторием по сети. Когда ты делаешь git clone, fetch или pull, опасный конфиг не приезжает - git собирает локальную копию с чистыми настройками. Клонирование по ссылке, даже с враждебного адреса, само по себе ничего не выполняет.

Опасен другой путь: когда репозиторий приходит к тебе как готовые файлы, вместе с папкой .git внутри. По словам Manifold, вектор - «всё, что переносит директорию, а не клонирует её»: присланный .zip, общий сетевой диск, папка в облачной синхронизации, флешка. Скачал архив с проектом, распаковал, открыл в агенте - и если внутри лежит заряженный .git/config, код уже выполнился.

Что получает атакующий - зависит от твоего окружения, но потолок высокий: SSH-ключи, облачные креды из переменных окружения, токены из конфигов оболочки, доступ ко всем репозиториям на диске. Один открытый архив - и чужой процесс шарит по твоей машине с твоими правами.

Кого затронуло и что уже починили

Manifold проверила несколько популярных агентов и подала отчёты в конце июня - июле. К публикации картина такая (версии - по данным исследователей, могли сдвинуться):

Claude Code - путь через core.fsmonitor закрыт в 2.1.196; отдельная ветка через команду ultrareview на момент разбора ещё срабатывала.
Goose - выдан CVE-2026-72718, исправлено в 1.44.0.
Cursor - пропатчен.
OpenAI Codex - пропатчен (Codex CLI с 0.131.0).
Hermes Agent - не исправлен, CVE-2026-71963; на попытки связаться разработчик не ответил.
Qwen Code - не исправлен.
Grok Build - не исправлен; xAI закрыла ранний отчёт как «информационный», не разобрав сам класс проблемы.

Manifold отдельно отмечает: приём встречается в большем числе агентов, чем перечислено. То есть список выше - не полный периметр, а те, до кого дотянулись руки исследователей.

Это уже проходили - в 2021 году

Самое отрезвляющее в этой истории - что грабли не новые. Ровно та же логика (git выполняется при открытии папки, до подтверждения доверия) укусила VS Code ещё в 2021 году. Тогда выпустили CVE-2021-43891 и починили в версии 1.63.1 простым, но твёрдым правилом: никаких git-операций, пока рабочая область не отмечена как доверенная. JetBrains следом закрыла своё по тому же принципу.

Модель «workspace trust» - спрашивать доверие к папке до того, как что-то по ней запускать - существует и проверена временем. А потом пришли ИИ-агенты и снова начали дёргать git при открытии, перепрыгнув уже построенный барьер. По данным Manifold, Anthropic ещё в ноябре 2025 переносила старт Claude так, чтобы ничего не выполнялось до подтверждения доверия, - но летом 2026 то же поведение вернулось в новой версии. Урок, который индустрия выучила пять лет назад, пришлось учить заново.

Как защититься

Разделю на два адресата, потому что ответственность здесь общая.

Если ты строишь агента. Санитизируй git-конфиг на всех фоновых вызовах, которые делает твой продукт. Manifold советует не чинить каждую точку по отдельности, а обернуть любой вызов git принудительным сбросом опасных ключей - например, git -c core.fsmonitor=false status. И более фундаментально - вернуть модель доверия VS Code: не трогать репозиторий, пока пользователь не подтвердил, что папке можно доверять.

Если ты просто пользуешься агентом. Держи в голове три привычки:

Обнови агента. Свежие версии закрывают уже известные пути.
Проверяй чужие папки до открытия. Прежде чем открыть присланную директорию в агенте, загляни в её настройки: git config --local --list покажет, что прописано в репозитории, а git config --get core.fsmonitor - есть ли там подозрительный помощник.
Не доверяешь источнику - не тащи его .git. Удали папку .git из присланного проекта и заново склонируй репозиторий из проверенного места. Клонирование по ссылке безопасно, а вот чужой .git внутри архива - нет.

Цепочка атаки: чужая папка с .git, агент зовёт git status, git читает .git/config, чужой код выполняется вне песочницы

Что важно понять из этой истории

Пока эксплуатации «в дикой природе» никто не подтвердил - это работа исследователей, а не разбор случившейся атаки. Но выводы шире одной уязвимости.

Первое: ИИ-агент - это не только модель. Вокруг неё стоит обвязка, которая сама по себе трогает файлы, запускает команды и доверяет инструментам. Дыра нашлась не в «уме» модели, а в том, как её оболочка обращается с git. Оценивать безопасность агента надо целиком, а не по тому, насколько он «умный».

Второе: удобная автоматизация и безопасность тянут в разные стороны. Агенту удобно сразу собрать контекст проекта - поэтому он и лезет в git при открытии. Ровно это удобство и стало вектором. Каждый раз, когда инструмент делает что-то «за тебя и заранее», стоит спросить, что он трогает без твоего ведома.

Третье, и самое практичное: относись к чужой папке как к чужому исполняемому файлу. Ты же не запускаешь наугад присланный .exe. Присланный репозиторий, открытый в агенте, теперь в той же категории риска.