Шумная версия звучит так: “0-day в AI-редакторе сам запускает код”. Полезная версия спокойнее. Mindgard утверждает, что Cursor на Windows может выполнить файл git.exe из корня открытого репозитория, когда ищет Git. Cursor отвечает, что риск узкий и относится к shared responsibility за untrusted workspace inputs. Практический вывод один: открыть неизвестный репозиторий в мощном AI-assisted developer tool — уже не совсем пассивное действие.

Рабочая станция разработчика: подозрительный executable в репозитории изолирован от секретов

Mindgard опубликовала technical disclosure в середине июля после процесса, который, по её словам, начался 15 декабря 2025 года. В proof of concept Windows Calculator переименовали в git.exe, положили в root репозитория, и он запускался при открытии проекта в Cursor. Это не история о prompt injection, не доказательство компрометации всех пользователей Cursor и не подтверждение такого же поведения на macOS/Linux. Preconditions важны: Windows, Cursor, malicious executable named exactly git.exe in repository root, and project loading behavior that triggers Git discovery.

Что именно утверждается

По Mindgard, Cursor при загрузке проекта проверяет несколько мест в поисках Git binary и может автоматически запустить git.exe из workspace. Cyber Security News писали, что Process Monitor показывал Cursor.exe, запускающий repo-root binary с git rev-parse --show-toplevel. The Hacker News добавили caveat: публичный write-up не доказывает окончательно, сам ли Cursor явно ищет workspace path или передаёт Windows unqualified git, после чего срабатывает Windows search order.

Для разработчика защиты разница невелика. В обоих вариантах файл внутри workspace становится executable до явного trust decision. Это старая категория: untrusted search path / current-directory executable resolution / CWE-426 или CWE-427. Новый контекст — AI coding IDE, который всё чаще сам инспектирует, запускает и меняет проекты.

Есть важное ограничение доказательств. The Hacker News сообщили, что последняя dated confirmation у Mindgard была Cursor 3.2.16 от 30 апреля, а current release в их материале был 3.11 от 10 июля. На момент подготовки статьи не найдено official Cursor advisory или CVE именно по repo-root git.exe. Это не доказывает ни “всё исправлено”, ни “все новые версии уязвимы”; это означает, что командам нужно проверять свой build, changelog and advisories.

Позиция Cursor

Cursor в forum response назвал report out of scope для bug bounty. Компания говорит о shared responsibility: клиенты решают, какие repos, prompts, MCP servers, rules and tools вводить в environment, а Cursor даёт controls for trust boundary. Cursor также подчёркивает narrow preconditions: Windows only, folder with malicious git.exe in root. В качестве mitigation компания указывает Workspace Trust / restricted mode. Одновременно Cursor признал process failure: не закрыл коммуникацию с researcher вовремя.

Это не бессмысленная позиция. Репозиторий может содержать malicious package scripts, hooks, binaries, task files and dependency traps. Но shared responsibility не снимает вопрос product responsibility. “Я открыл папку, чтобы прочитать код” отличается от “я разрешил запуск binary из этой папки”. Чем больше IDE автоматизирует project inspection and agent actions, тем строже должна быть граница между reading and running.

Почему спор на Hacker News был неизбежен

Одна сторона говорит: malicious executable in repo is already dangerous; Windows search behavior давно известен. Другая отвечает: cloning and opening repositories — нормальная работа разработчика, особенно при code review, bug reproduction and open-source maintenance. Разница между “пользователь сам запустил git в папке” и “editor запустил repo executable при открытии” — это и есть trust boundary.

Именно поэтому вокруг VS Code-derived tools существует Workspace Trust. Вопросы, которые задавали комментаторы, правильные: включён ли trust mode по умолчанию, блокирует ли Restricted Mode Git probing до execution, понимает ли пользователь, какие функции безопасны. Ответ не должен выясняться из длинного comment thread после full disclosure.

Не путать с DuneSlide

Параллельно обсуждались Cursor DuneSlide vulnerabilities, CVE-2026-50548 and CVE-2026-50549. Это другая история: prompt-injection paths escaping sandbox, reported by Cato AI Labs, fixed in Cursor 3.0 according to The Hacker News. Mindgard git.exe issue — не prompt injection и не model trick. Это local executable resolution во время project loading/Git discovery.

Но общий урок связан: AI coding tools собирают в один workflow чтение untrusted text, shell commands, file edits, package managers and secrets. Их нельзя считать обычным текстовым редактором.

Кто реально в зоне риска

Главный сценарий — Windows developer, который часто открывает unfamiliar repos in Cursor: maintainer, security engineer, DevOps/platform developer, AI-agent power user. Риск зависит не только от бага, но и от того, что доступно workstation: SSH keys, cloud credentials, package registry tokens, VPN, internal Git and browser sessions.

В проверенных источниках не найдено подтверждённой in-the-wild exploitation. Это снижает температуру, но не отменяет меры: изоляция нужна до того, как появится красивый incident report.

Что сделать разработчику

Обновите Cursor и следите за official release notes, security advisories and forum updates. Не считайте автоматически, что всё исправлено или всё сломано: проверьте свою версию и настройки.

Включите Workspace Trust / Restricted Mode для незнакомых папок. Первый запуск репозитория в IDE должен быть trust decision, а не безобидный preview.

Не открывайте произвольные repos на основном host. Используйте Windows Sandbox, VM, devcontainer, аккуратно настроенный WSL или disposable cloud dev environment. Цель — не идеальная паранойя, а отделение чужого кода от машины с ключами and production reach.

Перед открытием смотрите root проекта: неожиданные executables, git.exe, .cmd, .ps1, package wrappers, task files, hooks, extension recommendations. Это не audit, но obvious traps ловит.

Разнесите secrets: scoped tokens, short-lived credentials, hardware-backed keys where possible, separate accounts for experiments. Если unknown repo всё же получил execution, главным станет вопрос, что процесс мог украсть.

Что сделать командам

Нужна политика, которой разработчики смогут следовать: unknown repos only in isolated environments; production credentials outside general coding sessions; AI agents without broad cloud-admin privileges; PoC code in disposable VMs; mandatory Workspace Trust or equivalent controls.

На Windows fleets можно рассмотреть AppLocker или Windows Defender Application Control path rules against executables under workspace roots. Это может ломать legitimate workflows, поэтому сначала pilot. Parent-aware detection — например, Cursor.exe spawning binary from repository path — обычно требует EDR logic. Мониторьте editor child processes, доступ к SSH/cloud config and package publishing anomalies.

При выборе vendor спрашивайте не только про model quality. Важны bug bounty scope, advisory process, enterprise enforcement of trust settings, exact restricted-mode guarantees and response timelines.

Чего не делать

Не запускайте random PoC repos из любопытства. Не полагайтесь только на antivirus/SmartScreen или hash blocklists. Не превращайте это в “все пользователи Cursor уже взломаны”. И не говорите, что local malicious repo невозможен: современная разработка постоянно работает с чужим кодом. Правильный ответ — containment, not denial.

Главный урок

История не про панику вокруг Cursor. Она про developer workstation as attack surface. Расстояние между “посмотри этот репозиторий” и “запусти что-то на моей машине” сокращается. Пользователям нужно считать unknown repos executable content until proven otherwise. Командам — изолировать risky work, ограничивать secrets and monitor editor child processes. Вендорам — делать safer defaults and clearer disclosure.

Poisoned git.exe в корне репозитория — не киношный cyberattack. Это маленькая старая edge case, которая стала важнее из-за современных AI coding tools. Поэтому вывод спокойный: меньше истерики, больше ясной модели доверия.