ИИтог

У Cursor нашли 0-day с выполнением произвольного кода, без патча уже 7 месяцев

безопасностьРедакция ИИтогHacker News🔥80Рейтинг ИИтог · значимость 73 · 299 баллов · 27/ч · 142 коммент.
У Cursor нашли 0-day с выполнением произвольного кода, без патча уже 7 месяцев

Компания по кибербезопасности Mindgard опубликовала полное техническое описание 0-day уязвимости (уязвимости, для которой ещё нет патча) в Cursor, одном из самых популярных ИИ-редакторов кода. Суть проблемы: при загрузке проекта Cursor на Windows ищет исполняемые файлы git в нескольких местах, включая саму рабочую директорию проекта. Если заранее подложить в корень репозитория вредоносный файл git.exe, Cursor запустит его автоматически, без единого клика, диалога подтверждения или предупреждения. Происходит это не разово: пока проект остаётся открытым, редактор периодически повторно обращается к этому файлу, то есть подложенный код запускается снова и снова. В качестве безопасной демонстрации исследователи переименовали стандартное приложение Windows «Калькулятор» в git.exe и положили его в корень тестового репозитория: после открытия этого репозитория в Cursor на экране самостоятельно, одно за другим, стали появляться новые окна калькулятора, без какого-либо участия человека. В реальной атаке на месте калькулятора оказался бы произвольный вредоносный код, выполняющийся с правами текущего пользователя, то есть с доступом к файлам, учётным данным и терминалу разработчика. Масштаб продукта делает проблему особенно чувствительной: по данным Mindgard, у Cursor свыше 7 млн активных пользователей, более 1 млн заходят в редактор ежедневно, свыше 1 млн, платящие клиенты, продукт используют более 50 000 компаний, а рыночная оценка самой компании, $60 млрд. Хронология раскрытия растянулась на семь месяцев. Mindgard обнаружила уязвимость и в тот же день, 15 декабря 2025 года, сообщила о ней Cursor, по адресу для сообщений о безопасности, указанному в официальном файле security.txt компании. Подтверждения не последовало; после нескольких напоминаний исследователи попытались выйти на связь публично, чтобы найти нужный контакт внутри компании. В итоге ответил директор по информационной безопасности (CISO) Cursor: он признал, что из-за сбоя внутренней автоматизации отчёт не попал в ожидаемый процесс через платформу HackerOne. Mindgard пригласили в закрытую программу вознаграждений за уязвимости (bug bounty), и отчёт отправили повторно. Там его сначала закрыли со статусами «информационный» и «вне периметра» (Informative, out of scope). После того как Mindgard оспорила это решение, HackerOne заново открыла отчёт, воспроизвела уязвимость и подтвердила, что подробности переданы Cursor. А затем всё снова остановилось: запросы о статусе, эскалации через HackerOne и прямые обращения к руководству Cursor остались без ответа. Пока длилось это молчание, вышло более 70 новых версий Cursor, без каких-либо признаков того, что над исправлением вообще работают. На момент последней проверки, 30 апреля 2026 года, уязвимость всё ещё присутствовала в Cursor версии 3.2.16 на Windows, это подтверждено логами утилиты Sysinternals Process Monitor (инструмент мониторинга процессов Windows), зафиксировавшей автоматический запуск подложенного git.exe редактором. С момента первого обращения в декабре 2025 года прошло больше семи месяцев и вышло свыше 197 новых версий Cursor, но проблема так и не исправлена. Не добившись ответа от вендора, Mindgard решила прибегнуть к полному раскрытию (full disclosure), публикации всех технических деталей без ожидания патча. До выхода исправления компания рекомендует: администраторам управляемых корпоративных Windows-систем, настроить в AppLocker или Windows App Control запрещающие правила по имени и пути к файлу, привязанные к корням репозиториев и рабочих директорий (например, к каталогам вида «профиль пользователя → source → repos → любая подпапка → filename.exe»), а не по хешу файла, поскольку вредоносный бинарник легко пересобрать с другим хешем (стандартными средствами Windows нельзя запретить дочерний процесс только для конкретного родительского процесса, для этого нужны EDR или отдельные средства защиты конечных точек); обычным пользователям, до выхода патча открывать чужие или непроверенные репозитории только в изолированной виртуальной машине, Windows Sandbox или другом одноразовом окружении и не полагаться на блокировку по хешу файла. Исследователи используют этот случай, чтобы поставить более широкий вопрос, справляется ли вообще модель скоординированного раскрытия уязвимостей с потоком находок, который порождают быстро растущие ИИ-продукты. По их мнению, число таких находок растёт быстрее, чем способность вендоров их разбирать, а привычные процессы триажа (первичной обработки и оценки обращений), выстроенные почти два десятилетия назад, не справляются с новыми реалиями. Если конвейер раскрытия перегружен, считают в Mindgard, индустрии стоит прямо сказать об этом, а не оставлять исследователей и пользователей в неведении.

Ключевые факты

  • Уязвимость: при открытии проекта в Cursor на Windows редактор ищет git-бинарники в нескольких местах, включая саму рабочую директорию проекта; вредоносный git.exe в корне репозитория запускается автоматически, без кликов и предупреждений, причём повторно, пока проект остаётся открытым.
  • Демонстрация: исследователи Mindgard переименовали стандартный Windows-«Калькулятор» в git.exe, при открытии тестового репозитория в Cursor на экране самостоятельно, одно за другим, открывались новые окна калькулятора.
  • Масштаб: у Cursor свыше 7 млн активных пользователей, более 1 млн ежедневных, свыше 1 млн платящих, 50 000+ компаний-клиентов, рыночная оценка компании, $60 млрд.
  • Хронология: Mindgard сообщила об уязвимости 15 декабря 2025 года; отчёт застрял из-за сбоя автоматизации HackerOne, затем его закрыли как неинформативный, после протеста переоткрыли и подтвердили доставку Cursor, а дальше наступило молчание (70+ версий вышло без ответа о статусе).
  • Спустя более семи месяцев и свыше 197 новых версий уязвимость по-прежнему не исправлена (проверено 30 апреля 2026 года на версии 3.2.16); Mindgard пошла на полное раскрытие и опубликовала рекомендации по временным мерам защиты для корпоративных и обычных пользователей.

Почему это важно

Cursor, один из самых массовых ИИ-редакторов кода: свыше 7 млн активных пользователей, более 1 млн платящих клиентов, 50 000+ компаний-клиентов и рыночная оценка в $60 млрд. При этом обнаруженная уязвимость, не сложная теоретическая атака через промпт-инъекции или манипуляции моделью, а предельно простой сценарий: открыл чужой репозиторий, получил выполнение произвольного кода без единого клика. Инструмент такого масштаба получает от разработчиков доступ к исходному коду, учётным данным, терминалу и растущему набору автономных возможностей, поэтому цена подобной уязвимости и цена молчания вендора о ней оказываются особенно высокими.

Кому это важно

В первую очередь, разработчикам и командам, использующим Cursor на Windows и открывающим в нём сторонние или непроверенные репозитории: чужие open-source библиотеки, форки, пул-реквесты, тестовые задания для собеседований и подобное. Дальше, ИБ-отделам компаний, которым, раз патча нет, приходится самим настраивать компенсирующие меры на уровне корпоративной политики Windows. И шире, всей индустрии ИИ-инструментов для разработки: история поднимает вопрос, справляется ли модель скоординированного раскрытия уязвимостей с потоком находок, который порождают быстро растущие ИИ-продукты.

Как это применить

Патча пока нет, поэтому Mindgard предлагает временные меры. Администраторам управляемых Windows-систем: настроить в AppLocker или Windows App Control запрещающие правила по имени и пути к файлу, привязанные к корням репозиториев и рабочих директорий (например, к каталогам вида «профиль пользователя → source → repos → любая подпапка → filename.exe»), а не по хешу файла, вредоносный бинарник легко пересобрать с другим хешем. Стандартными средствами Windows нельзя запретить дочерний процесс только для конкретного родительского процесса, для этого нужны EDR (системы обнаружения и реагирования на угрозы на конечных точках) или отдельные средства защиты конечных точек. Обычным пользователям, до выхода патча открывать чужие или непроверенные репозитории только в изолированной виртуальной машине, Windows Sandbox или другом одноразовом окружении, и не полагаться на блокировку по хешу файла.

Можно ли доверять

Материал написан самой исследовательской компанией, обнаружившей уязвимость, это стоит держать в уме. Но степень детализации работает на достоверность: указана точная дата обнаружения (15 декабря 2025 года), точная версия и дата последней проверки (Cursor 3.2.16, 30 апреля 2026 года), приведены логи Sysinternals Process Monitor с точными временными метками и путями, а демонстрационный сценарий, переименованный в git.exe Windows-«Калькулятор», предельно простой и легко проверяемый независимо. Ключевой факт, что отчёт был подтверждён самой платформой HackerOne, которая воспроизвела уязвимость и подтвердила доставку деталей Cursor, исходит не только от Mindgard. При этом собственно позиции Cursor по существу проблемы в статье нет: единственная приведённая реакция компании, признание её CISO сбоя внутренней автоматизации, без комментариев по срокам исправления.

Риски и подводные камни

Пока патча нет, любое открытие чужого или непроверенного репозитория в Cursor на Windows может обернуться незаметным выполнением произвольного кода с правами текущего пользователя, с доступом к файлам, учётным данным и терминалу разработчика. Блокировка по хешу файла не спасает: атакующий может пересобрать вредоносный git.exe с любым хешем, а Windows не умеет из коробки ограничивать дочерний процесс только для конкретного родителя. Есть и более широкий риск помимо самой уязвимости: если, как утверждает Mindgard, конвейеры скоординированного раскрытия перестают справляться с потоком находок для ИИ-продуктов, а вендоры неделями и месяцами не отвечают даже после отчётов, подтверждённых сторонними платформами вроде HackerOne, это подрывает доверие ко всей практике ответственного раскрытия уязвимостей.

«Полное раскрытие, это «ядерный вариант» в практике раскрытия уязвимостей, к которому прибегают, когда все остальные пути исчерпаны. Он существует не просто так: если вендор перестаёт выходить на связь, пользователей нельзя оставлять в неведении.»

— Mindgard