Вредоносный Git-репозиторий может атаковать AI-агента программиста

Открыть чужой Git-репозиторий в AI-агенте теперь может быть не такой безобидной операцией, как кажется. Исследователи Manifold Security нашли несколько способов заставить популярные AI-инструменты выполнять команды через настройки самого Git. Пользователю для этого достаточно работать с подготовленным репозиторием.

Исследование GitSpawn затронуло семь AI-кодинговых агентов и выявило восемь проблем. Среди них были Claude Code, OpenAI Codex, Cursor, Goose, Qwen Code, Grok Build и Hermes Agent. Часть уязвимостей разработчики уже закрыли, но сама схема атаки интересна гораздо больше отдельных исправлений.

Дело в том, что агенту для работы с проектом приходится взаимодействовать не только с исходниками.

Что происходит внутри репозитория

Когда разработчик просит AI-агента разобраться с проектом, тот может самостоятельно проверить состояние Git, посмотреть изменения или получить другую информацию о рабочей директории.

Git при этом обращается к собственной конфигурации. И некоторые параметры этой конфигурации можно использовать неожиданным способом.

Исследователи продемонстрировали сценарий с core.fsmonitor. Эта настройка существует для вполне нормальной задачи - ускорения работы Git в больших репозиториях. Но если злоумышленник заранее подготовит репозиторий определённым образом, обращение агента к Git может привести к запуску заданной команды.

То есть разработчик может не писать в терминале ничего вроде ./malicious-script.sh. Агент сам выполняет обычную Git-операцию, а дальше срабатывает уже механизм Git.

Именно поэтому такая атака выглядит неочевидно.

Почему разрешение на команду может ничего не решить

AI-кодинговые агенты обычно пытаются контролировать опасные действия. Пользователь может получать запрос перед выполнением команды, а некоторые инструменты дополнительно изолируют агента в sandbox.

Но GitSpawn показывает неприятный вариант обхода этой логики.

Команда может появиться как побочный эффект работы Git, а не как отдельное решение агента выполнить неизвестный скрипт. В некоторых из описанных исследователями сценариев выполнение происходило вне sandbox агента и без отдельного подтверждения пользователя.

Для разработчика всё выглядит вполне буднично: он открыл проект и попросил агента посмотреть, почему не работает код.

Агент начинает разбираться.

Самый простой сценарий - чужой проект

Допустим, кто-то прислал репозиторий с тестовым заданием. Или разработчик нашёл на GitHub небольшую библиотеку и решил попросить AI объяснить её устройство.

Проект скачивается локально, после чего открывается в Cursor, Codex или другом агенте.

В обычной ситуации человек мог бы сначала посмотреть файлы, затем проверить Git и только потом начать что-то запускать. Агент действует быстрее. Ему нужно собрать контекст, поэтому он сам начинает обращаться к инструментам проекта.

Если репозиторий специально подготовлен злоумышленником, эта автоматизация становится проблемой.

В этом и заключается интерес GitSpawn: атакующему не обязательно рассчитывать на то, что программист сознательно запустит подозрительный файл. Можно попытаться дождаться, пока это сделает AI-агент в процессе своей обычной работы.

Почему проблема касается сразу нескольких AI-инструментов

В исследовании оказалось восемь проблем в семи агентах. Это важнее самого списка пострадавших продуктов.

Если бы речь шла об одной ошибке в конкретном приложении, её можно было бы закрыть обновлением и забыть. Здесь повторяется один и тот же архитектурный сценарий: AI получает возможность самостоятельно пользоваться инструментами разработчика, а эти инструменты имеют собственные механизмы автоматического выполнения.

OpenAI Codex и Cursor, например, фигурировали среди затронутых систем, но связанные с ними проблемы были исправлены. Ситуация с отдельными агентами меняется по мере выхода обновлений, поэтому старую версию инструмента использовать особенно рискованно.

И это, пожалуй, самое интересное последствие появления автономных coding agents.

AI становится посредником между кодом и системой

Раньше программист в основном сам решал, что произойдёт после открытия репозитория. Теперь часть этих решений принимает агент.

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

GitSpawn хорошо показывает, где здесь слабое место.

Безопасность AI-агента нельзя рассматривать отдельно от безопасности инструментов, которыми он пользуется. Даже если сама модель отказывается выполнять подозрительную команду, это ещё не означает, что команда не появится через другой компонент цепочки.

Для разработчика практический вывод довольно простой: чужой репозиторий стоит считать недоверенным окружением, даже если в нём нет очевидного вредоносного скрипта.

Особенно если проект сразу открывается в AI-агенте, которому разрешено работать с терминалом и локальными файлами.

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