15 декабря 2025 года исследователи из Mindgard сообщили Cursor об уязвимости, которая на Windows позволяет автоматически запустить вредоносный файл из корня репозитория. Спустя семь месяцев проблема, по данным Dark Reading, все еще воспроизводится: для команд, которые уже привыкли открывать чужие проекты в AI-IDE, это плохая новость безо всякой драматургии.
Суть истории неприятно простая. Исследователи утверждают, что Cursor при загрузке проекта ищет Git-бинарник в нескольких местах, и одно из них — сама рабочая директория. Если атакующий подложит в корень репозитория вредоносный git.exe, клиент Cursor может выполнить его автоматически, без отдельного предупреждения и без запроса подтверждения. То есть сценарий «открыл репозиторий — получил запуск чужого кода» здесь выглядит не как теоретическая цепочка из десяти шагов, а как почти прямой путь к компрометации рабочей машины разработчика.
В качестве демонстрации Mindgard взяла обычный калькулятор Windows, переименовала его в git.exe и положила в корень тестового репозитория. Этого, по словам исследователей, оказалось достаточно: при открытии проекта в Cursor файл исполнился. Понятно, что в реальной атаке вместо калькулятора может быть не безобидный PoC, а удаленный троян, загрузчик шифровальщика или любой другой полезный для атакующего бинарник. И именно в этом главная проблема: poisoned repository attack обычно требует от жертвы хотя бы какого-то лишнего действия, а здесь трение сведено почти к нулю.
Отдельный слой этой истории — disclosure process, и он для вендора выглядит не лучше, чем сама техническая ошибка. Mindgard пишет, что после первого сообщения от 15 декабря 2025 года несколько раз возвращалась к теме в течение следующих шести месяцев: через email, LinkedIn и программу bug bounty на HackerOne. Однако, по версии исследователей, Cursor не приняла отчет, не закрыла проблему и не дала внятного статуса по исправлению. Dark Reading получила комментарий представителя Cursor 13 июля 2026 года: компания подтвердила, что занимается проблемой и свяжется с Mindgard. Формально это уже реакция. Практически это означает, что уязвимость Cursor IDE дожила до публичного раскрытия без патча, а пользователи все это время оставались один на один со своими компенсирующими мерами.
Для российского и вообще русскоязычного IT-рынка здесь важен не только сам баг, но и более широкий контекст. AI-IDE, AI-агенты и автодополнение кода уже давно продаются не как игрушка для хакатона, а как рабочий инструмент для продакшна. Их ставят на ноутбуки разработчиков, дают командам доступ к корпоративным репозиториям, подключают к внутренним сервисам и нередко запускают с теми же правами, что и обычную среду разработки. В такой схеме любая ошибка на границе между локальной машиной, файловой системой и исполняемыми файлами превращается из «неприятного бага» в готовую точку входа. Особенно если речь идет о разработчиках, которые регулярно клонируют внешние проекты, проверяют тестовые репозитории, смотрят чужие демо или берут шаблоны из open source.
Есть и еще один неприятный нюанс: poisoned repo атаки хорошо ложатся на привычки современной разработки. Мы все уже привыкли, что репозиторий может содержать скрипты, хуки, devcontainer-конфиги, package manager-файлы, CI-описания и еще с десяток сущностей, которые что-то запускают, подтягивают или настраивают. На этом фоне лишний бинарник в корне проекта для кого-то может вообще не выглядеть красным флагом, особенно если он замаскирован под служебный файл. Уязвимость Cursor IDE здесь опасна именно тем, что убирает последний защитный барьер в виде явного действия пользователя. Если среда сама исполняет то, что нашла в рабочем каталоге, проверка репозитория превращается в постфактум, а не в профилактику.
Что делать прямо сейчас, пока исправление не вышло или не развернуто у вас в компании? Mindgard рекомендует для enterprise- и managed-Windows-сред использовать AppLocker или Windows App Control, чтобы запретить запуск git.exe из директорий разработческих рабочих пространств. Для обычных пользователей рекомендация еще жестче: не открывать недоверенные репозитории в основной системе, а использовать изолированную виртуальную машину, Windows Sandbox или другую одноразовую среду. Отдельно исследователи предупреждают, что блоклисты по хэшу тут плохой помощник: злоумышленнику достаточно пересобрать или слегка изменить бинарник, и защита рассыпается. Для тимлидов и IT-директоров вывод тоже вполне приземленный: AI-инструменты разработки пора оценивать по тем же правилам, что браузеры, мессенджеры и VPN-клиенты, то есть как софт с прямым влиянием на корпоративный периметр.
Самый неудобный вопрос во всей истории звучит так: сколько еще подобных shortcut-решений спрятано внутри AI-инструментов, которые мы успели записать в безопасные по умолчанию? Чем глубже IDE встраивается в цепочку разработки и чем больше прав получает на машине инженера, тем дороже обходится любая логика вида «удобно сейчас, разберемся потом». История с Cursor здесь интересна не только как конкретная уязвимость, но и как напоминание: рынок AI for dev tools растет быстрее, чем привычка относиться к этим продуктам с нормальной паранойей.