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