Патч для кодинг-агентов выпустили, но `git status` в чужом репозитории всё ещё может запустить вредоносный код
1 сентября Manifold Security опубликовала исследование GitSpawn. В нём описаны восемь уязвимых сценариев в семи инструментах для работы с кодом на базе ИИ-агентов.
Проблема сводится к простой ситуации: вам передают папку с проектом, вы открываете её в агенте - и на компьютере выполняется команда, которую вы не вводили и не запускали вручную.
Как вредоносный код запускается через Git
В Git существует параметр `core.fsmonitor`. Он указывает команду, которую Git запускает автоматически, чтобы определить, какие файлы изменились. Настройка хранится в локальном файле `.git/config`, то есть непосредственно внутри конкретного репозитория.
Когда Git обновляет индекс или анализирует состояние проекта, он может обратиться к этой команде. Поэтому опасный сценарий срабатывает не только при выполнении сложных операций. Иногда достаточно обычных действий:
- `git status`;
- `git diff`;
- запуска сборочного скрипта;
- проверки текущей ветки;
- открытия проекта в редакторе;
- фонового анализа файлов кодинг-агентом.
Иными словами, пользователь может не вводить никаких команд. Достаточно открыть присланную папку, после чего агент самостоятельно вызовет Git для сбора контекста. Вредоносный код способен выполниться ещё до первого запроса пользователя и иногда даже раньше окна с предложением доверять рабочей области.
Для проверки исследователи создали специальный репозиторий-ловушку. После выполнения всего одной команды `git status` встроенный скрипт запустился. Это демонстрирует главное ограничение выпущенных исправлений: патч агента защищает только фоновые вызовы Git, которые выполняет сам агент.
Почему обновление агента не решает проблему полностью
Claude Code устранил один из путей атаки через `core.fsmonitor` в версии 2.1.196. Проверка на версии 2.1.271 показала, что в аналогичной папке-ловушке вредоносная нагрузка уже не запускалась. Исправления также получили Codex, Cursor и Goose.
Однако если после этого открыть ту же папку в обычном терминале и самостоятельно набрать `git status`, команда из конфигурации всё ещё может выполниться. То же относится к любому другому инструменту, который обращается к Git.
Это может быть:
- редактор с Git-интеграцией;
- `make` или другой сборщик;
- локальный скрипт разработки;
- Git-плагин;
- CI-раннер;
- оболочка, автоматически показывающая ветку;
- утилита, проверяющая изменения перед запуском.
Вредоносный репозиторий остаётся опасным независимо от того, каким способом впервые был вызван Git.
Кроме того, исправления внедрялись точечно. Разработчики агентов блокировали конкретные места, из которых выполнялись опасные Git-команды, но не устраняли саму возможность выполнения чужой конфигурации. Новый функционал может добавить ещё один путь к Git и повторно открыть аналогичный сценарий.
Manifold Security также сообщила Anthropic о втором маршруте атаки в Claude Code, не связанном напрямую с `core.fsmonitor`. На момент публикации исследования он оставался незакрытым в версии 2.1.252.
На 1 сентября уязвимыми также считались Qwen Code, Grok Build и Hermes Agent.
Отдельная проблема: вложенные bare-репозитории
Существует и другой вектор атаки, связанный с вложенным bare-репозиторием. Обычный каталог с именем `.git` нельзя корректно разместить внутри другого репозитория: Git блокирует такой путь при добавлении файлов.
Но bare-репозиторию не обязательно иметь привычную структуру рабочей копии. Ему достаточно каталогов `HEAD`, `objects` и `refs`. Эти элементы можно сохранить внутри обычного проекта. Во время обхода дерева Git способен обнаружить такую структуру и применить находящуюся там конфигурацию.
Для GitHub Copilot CLI этот сценарий получил отдельный идентификатор CVE-2026-45033. Исправление вошло в версию 1.0.43.
Клонирование репозитория здесь ни при чём
Важно отличать безопасный сценарий клонирования от передачи готовой папки.
Команды `git clone`, `git fetch` и `git pull` сами по себе не запускают такой payload. Опасность появляется, когда к пользователю попадает уже сформированная директория с вложенным `.git` или похожей структурой.
Папка может прийти в виде:
- ZIP-архива;
- каталога на общем диске;
- проекта из облачной синхронизации;
- содержимого флешки;
- набора файлов из мессенджера;
- рабочего каталога, переданного коллегой.
После распаковки достаточно просто открыть директорию, перейти в неё в терминале или запустить редактор с автоматической Git-интеграцией.
Как проверять чужую папку
Проверять нужно не агент, а сам каталог до первого входа в него через инструменты, которые могут обратиться к Git. Полезная диагностическая команда должна анализировать:
- `.git/config`;
- параметры, значения которых Git способен выполнять;
- вложенные bare-репозитории;
- `.gitattributes`;
- каталоги `.husky`;
- `.devcontainer`;
- `postinstall` и другие install-скрипты;
- конфигурации, влияющие на автоматические действия редактора и сборщика.
Если проверка обнаруживает подозрительные элементы, она должна возвращать ненулевой код завершения. Тогда её можно подключить к pre-commit, CI или внутреннему процессу приёма сторонних проектов.
Такая проверка особенно важна для команд, которые регулярно получают исходники от внешних разработчиков, принимают тестовые задания или запускают ИИ-агентов в автоматически загруженных рабочих каталогах.
Как временно работать с подозрительным репозиторием
Если анализировать проект нужно прямо сейчас, опасные механизмы можно отключить на уровне команды или окружения, не полагаясь на настройки самой папки.
В частности, применяют следующие меры:
- отключают `core.fsmonitor`;
- запрещают автоматическое обнаружение вложенных bare-репозиториев;
- задают безопасные параметры Git через командную строку или переменные окружения;
- запускают работу в изолированном контейнере;
- ограничивают доступ процесса к домашнему каталогу, SSH-ключам и секретам;
- используют отдельную виртуальную машину для непроверенного кода.
Принципиально важно, чтобы защитная настройка имела более высокий приоритет, чем конфигурация из самого репозитория. Иначе вредоносный проект сможет переопределить защиту собственными параметрами.
При таком запуске `git status` может успешно отработать, но команда из ловушки не выполнится. Однако это не означает, что проект стал безопасным: остаются сборочные скрипты, хуки, контейнерные конфигурации и зависимости с автоматическими сценариями установки.
Почему опыт VS Code оказался забыт
Класс подобных проблем не новый. VS Code ещё в 2021 году внедрил механизм доверия к рабочей области. Он предупреждает пользователя перед включением функций, способных выполнять код, и разделяет безопасный просмотр файлов и полноценную работу проекта.
Появление кодинг-агентов вернуло старый риск в новой форме. Агенту нужно самостоятельно изучать структуру проекта, запускать Git, читать конфигурацию и собирать контекст. Поэтому он может обратиться к опасной настройке раньше, чем пользователь успеет принять осознанное решение.
Особенно рискованны режимы, в которых агент автоматически запускается при открытии каталога, выполняет команды без подтверждения или имеет доступ к переменным окружения и файловой системе.
Практический порядок действий
Перед запуском агента в незнакомом проекте стоит придерживаться последовательности:
1. Распаковать архив в отдельную временную директорию.
2. Не переходить в неё командой `cd` до первичной проверки.
3. Просмотреть содержимое скрытых файлов и каталогов.
4. Проверить `.git/config` и наличие вложенных структур репозитория.
5. Изучить хуки, install-скрипты и конфигурацию контейнеров.
6. Запускать проект с минимальными правами.
7. Не предоставлять непроверенному агенту доступ к SSH-ключам, токенам и рабочим секретам.
8. Использовать контейнер или виртуальную машину, если происхождение файлов неизвестно.
9. Только после проверки открывать каталог в IDE или кодинг-агенте.
Главный вывод GitSpawn заключается в том, что угрозой может быть не только команда, которую агент собирается выполнить. Иногда достаточно файла конфигурации, который заставит привычную команду вроде `git status` сделать это самостоятельно. Поэтому безопасный момент наступает не после запуска агента, а до первого обращения к чужой папке.