Откройте репозиторий в Cursor в Windows, и если в корневом каталоге проекта находится файл с именем git.exe, Cursor запустит его. Никаких кликов, никаких диалоговых окон с запросом подтверждения, никаких предупреждений о том, что что-то в этой папке вот-вот будет запущено.
Что бы ни делал этот бинарник, он действует от вашего имени, используя ваш исходный код, ваши SSH-ключи и ваши облачные токены. Cursor продолжает запускать его до тех пор, пока проект остаётся открытым.
Никакой инъекции команд, никакого агента, никакой модели в цикле и никакого предварительного доступа к машине: открытие папки и есть весь эксплойт, а результатом становится выполнение произвольного кода от имени вошедшего в систему пользователя.
Компания Mindgard, специализирующаяся на безопасности ИИ, сообщила о данной уязвимости Cursor 15 декабря 2025 года и опубликовала полные технические детали во вторник, семь месяцев спустя. Исправления до сих пор нет, и Cursor не выпустила никакого уведомления по данной проблеме.
Описание механизма занимает примерно одно предложение. При загрузке проекта Cursor проверяет несколько мест на наличие бинарного файла Git, и одним из них является сама рабочая область. Вывод Process Monitor в описании показывает, что Cursor.exe запускает бинарный файл в корне репозитория с помощью командной строки git rev-parse --show-toplevel.
Это тот же самый механизм проверки корня репозитория, который описан в документации VS Code от Microsoft. В статье не уточняется, проводит ли Cursor поиск по этим местам самостоятельно или передаёт Windows неопределённый аргумент «git» и позволяет системе Windows выбирать порядок поиска.
В качестве доказательства концепции Mindgard использовал калькулятор Windows, переименованный в git.exe и зафиксированный в корневом каталоге. Клонировать, открыть — готово. На скриншоте видно, как окна калькулятора сами по себе накапливаются, пока проект остаётся открытым.
Казалось бы, самое сложное — это создание исходных условий: наличие бинарного файла злоумышленника в корневом каталоге вашего проекта. Но это не так. Клонирование чужого репозитория — это именно тот способ, с помощью которого бинарные файлы попадают на диск, и разработчики и их агенты делают это постоянно. Злоумышленнику изначально не нужен никакой «плацдарм». Именно этот путь и охватывает данная уязвимость: от репозитория, который может опубликовать любой, до кода, запущенного от вашего имени.
Одно ограничение в отношении доказательств. Самое последнее датированное подтверждение от Mindgard относится к 30 апреля 2026 года и касается версии Cursor 3.2.16, тогда как текущая версия — 3.11, выпущенная 10 июля. В отчёте говорится, что уязвимость сохраняется в самой новой протестированной версии, но конкретная версия не указана.
Сайт Hacker News проанализировал все 33 уведомления о безопасности, опубликованные Cursor, и по состоянию на 15 июля не обнаружил ни одной записи, касающейся данной проблемы. CVE-идентификатор не присвоен. Мы обратились к Cursor с просьбой указать версию, в которой исправлена эта уязвимость, а к Mindgard — версию, в которой она тестировалась в последний раз. Эта статья будет обновлена при поступлении ответов.
Патча нет, поэтому все приведенные ниже варианты являются обходными решениями. Для управляемых парков компьютеров под Windows компания Mindgard рекомендует использовать правила запрета в AppLocker или Windows App Control, которые блокируют исполняемый файл по имени и пути в корневых каталогах рабочих пространств, например: %USERPROFILE%\source\repos\*\filename.exe.
Используйте правила по пути, а не по хешам; бинарные файлы злоумышленников различаются по хешам. Компания отмечает, что в Windows нет общего встроенного правила, которое блокировало бы дочерний процесс только в том случае, если его запускает конкретный родительский процесс, поэтому принудительное применение с учетом родительского процесса обычно означает использование EDR. Всем остальным: открывайте ненадежные репозитории в одноразовой виртуальной машине или Windows Sandbox.
Совместите это с советом Cymulate: проверяйте клонированный репозиторий или извлечённый архив перед тем, как открывать его. git.exe, npx.exe, node.exe и where.exe не должны находиться в корневом каталоге проекта. Что произошло с отчётом — это уже другая история.
На странице Cursor, посвящённой безопасности, указано, что компания подтверждает получение «сообщений об уязвимостях в течение 5 рабочих дней». Первый содержательный ответ от Mindgard поступил через месяц после декабрьского сообщения — его направил директор по информационной безопасности (CISO) Cursor, который пояснил, что из-за сбоя в автоматизации компания не была приглашена в закрытую программу HackerOne.
Повторно отправленный отчет был закрыт на следующий день как «информативный и выходящий за рамки», а затем вновь открыт после того, как Mindgard выразила несогласие, и HackerOne воспроизвела уязвимость. HackerOne подтвердила получение отчета 20 января. После этого: запросы на обновление в феврале, марте и апреле — и никакого ответа.
Анализ истории уведомлений Cursor в сопоставлении с хронологией событий Mindgard показывает, что процесс работал для других исследователей, в то время как отчет Mindgard оставался без внимания. 13 февраля 2026 года Cursor опубликовала GHSA-8pcm-8jpx-hv8r — уязвимость, позволяющую выйти из песочницы через Git-hook (CVE-2026-26268), о которой сообщила компания Novee в рамках скоординированного раскрытия и которая была исправлена в Cursor 2.5. Через три дня, 16 февраля, Mindgard запросила информацию о ходе рассмотрения своего собственного отчета, связанного с Git. Ответа не последовало. Ещё два уведомления Cursor были опубликованы 14 июля — в тот же день, когда состоялось полное раскрытие информации.
«Полное раскрытие — это крайняя мера при раскрытии уязвимостей», — написала Mindgard, оставляя её на те случаи, когда все остальные пути оказались безрезультатными. Автор, Аарон Портной, много лет проработал на другой стороне этой сферы: он руководил Zero Day Initiative и организовал первые шесть конкурсов Pwn2Own.
Mindgard — не первая компания, обнаружившая эту проблему, и не первая, получившая ответ от Cursor по этому поводу. В июне компания Cymulate опубликовала результаты исследования, касающиеся идентичного класса уязвимостей в инструментах искусственного интеллекта: в Windows некоторые из этих инструментов определяют расположение вспомогательных исполняемых файлов, используя порядок поиска по умолчанию, при котором рабочий каталог проверяется раньше, чем доверенные системные пути.
CLI-версия GitHub Copilot запускала git.exe рабочей области при запуске, ещё до того, как появлялся запрос на доверие к папке. CLI-версия Gemini делала то же самое при запуске из рабочей области. Настольное приложение Codex делало это при открытии папки, как и Cursor.
По состоянию на отчет Cymulate от 4 июня ни один из этих поставщиков не выпустил исправления. GitHub рассмотрел отчет и выплатил вознаграждение, а затем понизил уровень уязвимости до «низкого». Google согласилась с тем, что вывод по Gemini CLI был обоснован, но не выпустила исправления. OpenAI закрыла отчет по Codex как «Неприменимо», мотивируя это тем, что злоумышленник, способный заменить git.exe, уже имеет доступ к системе. Однако это не соответствовало описанному в отчете сценарию. Cursor закрыла отчет Cymulate по Cursor CLI как «Информативный» через восемь дней, мотивируя это тем, что обнаруженные уязвимости, требующие наличия вредоносного бинарного файла, «не имеют вектора атаки».
Это исследование всё же привело к одному исправлению. AWS присвоила CVE-2026-10591 обнаруженной в Kiro уязвимости, указала Cymulate в качестве автора и исправила её в версии Kiro 0.11. Но это была другая уязвимость: недостаток в механизме записи файлов агентом, позволявший заражённому файлу .vscode/tasks.json автоматически запускаться при открытии папки. Ни один из отчётов о подмене бинарных файлов не привёл к появлению подобного исправления.
Эта категория уязвимостей появилась ещё до всего этого. Слабым местом является недоверенный путь поиска; атака заключается в подмене бинарного файла в том месте, где его найдёт поиск. Проверка Windows текущего каталога перед %PATH% и стала причиной сбоя в работе Git Credential Manager Core в 2020 году (CVE-2020-26233): вредоносный файл git.exe, расположенный на верхнем уровне репозитория, запускался вместо подлинного во время рекурсивного клонирования. Исправлено в GCM 2.0.289.
Показатель работоспособности (PoC) от Blaze Information Security в то время также представлял собой файл calc.exe, переименованный в git.exe. Спустя шесть лет тот же трюк срабатывает против IDE, которая запускает зонд за вас в тот момент, когда вы открываете папку.
Четырём поставщикам уже продемонстрировали бинарный файл рабочей среды, запускающийся в Windows, как только разработчик наводит инструмент на клонированный репозиторий. Двое решили, что это вовсе не уязвимость; двое согласились, что это уязвимость, и, согласно отчёту Cymulate за июнь, всё равно ничего не выпустили. Таким образом, решение остается за защитниками, и в Windows безопаснее всего рассматривать клонированный репозиторий как исполняемый контент, потому что именно этим он и является.