DEV Community

Cover image for Cursor 3.2.16 на Windows: 14 июля раскрыли PoC — git.exe в root непроверенного репозитория запускался при открытии. Как…
Promptra Team for provod.ai

Posted on

Cursor 3.2.16 на Windows: 14 июля раскрыли PoC — git.exe в root непроверенного репозитория запускался при открытии. Как…

14 июля Mindgard раскрыл PoC, в котором Cursor на Windows при открытии проекта находил и запускал git.exe, лежащий в корне репозитория. Для демонстрации исследователи переименовали Windows Calculator в git.exe и поместили его в папку проекта. Отдельный клик по файлу или запрос на подтверждение не требовались.

Это меняет практическое правило для Cursor: незнакомый репозиторий нельзя считать просто набором исходников, пока его не открыли в изолированной среде. Риск не в самом Git и не в каждом проекте из интернета, а в том, что поиск исполняемого файла мог учитывать содержимое workspace.

Что именно подтверждено

Публично названная проверка относится к Cursor 3.2.16 на Windows и датирована 30 апреля. Условие атаки тоже конкретно: пользователь должен получить poisoned repository локально и открыть его в редакторе. Это не утверждение о «удалённом zero-click» без участия человека и не свидетельство для macOS или Linux.

Механизм важнее эффектной демонстрации. Если инструмент при открытии workspace ищет git.exe так, что файл из корня проекта оказывается подходящим кандидатом, репозиторий влияет не только на текст кода и конфигурацию, но и на выбор программы для запуска. Тогда привычное действие «посмотреть проект» становится границей исполнения.

После семи месяцев disclosure Mindgard опубликовал детали. Обсуждение быстро вышло за пределы одного отчёта: соответствующая публикация на Hacker News получила 453 points и 202 комментария. Это не измерение распространённости уязвимости или знакомости разработчиков с этим классом риска, а показатель интереса и обсуждаемости именно этого треда.

Где заканчивается доказательство

Самая опасная ошибка сейчас, вероятно, не недооценить PoC, а расширить его дальше фактов. Более новая версия 3.11 публично не проверялась исследователем в описанном тесте. Поэтому фраза «последний Cursor точно уязвим» не подтверждена.

Cursor отнёс этот сценарий к области вне программы bug bounty, сославшись на shared responsibility и Workspace Trust. Это сильное возражение: среда разработки действительно не может полностью заменить пользователю оценку происхождения проекта, а доверие к workspace должно влиять на рискованные действия.

Но здесь остаётся практический вопрос. Публикации не дают независимой окончательной проверки, блокирует ли Workspace Trust именно описанный Git probe. До такого ответа настройку доверия разумно считать дополнительным барьером, а не единственной защитой.

Схема пути от открытия репозитория к поиску git.exe

Решение: разделить просмотр и доверие

Для незнакомого репозитория полезен короткий режим принятия решения.

  1. До открытия проверьте корень распакованной папки на исполняемые файлы, особенно на имена инструментов, которые среда может искать.
  2. Если проект нужен только для первичного осмотра, открывайте его в Windows Sandbox или disposable VM.
  3. Не подключайте к такой среде рабочие секреты, токены и другие чувствительные данные.
  4. В управляемой Windows-среде используйте path-based правило AppLocker или политику Windows App Control, ограничивающую запуск из путей, где появляются чужие репозитории.
  5. Не полагайтесь только на блокировку по хешу: она не решает проблему, когда вредоносный файл может быть пересобран или заменён.

Это не повод перестать пользоваться внешними библиотеками, примерами и тестовыми проектами. Это повод отделить «я хочу прочитать код» от «я готов дать папке участвовать в поиске исполняемых программ».

Когда команда регулярно исследует внешние репозитории, полезна инфраструктурная граница: сначала распаковать и проверить проект в disposable environment, не монтировать секреты и фиксировать события исполнения. Такой режим можно выстроить в provod.ai как отдельный контур для agentic coding, не предполагая, что сам сервис запускает Cursor.

Карточка безопасного режима для незнакомых репозиториев


provod.ai — корпоративная работа с AI с учётом требований РФ

Для сценариев с персональными данными важна не только модель, но и организация процесса: платформа проектируется с учётом требований российского законодательства, а применимость определяется составом данных и настройками клиента.

В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.

Требования к корпоративному процессу не увеличивают тариф модели: стоимость сохраняется 1:1 с официальной ценой провайдера, без собственной наценки provod.ai.

Изучите условия для корпоративного сценария: форма регистрации · цены на модели · защита данных по 152-ФЗ · политика обработки данных

Что для вашей команды дороже: несколько минут на изолированный первый запуск каждого внешнего репозитория или право открывать их сразу в рабочем окружении с секретами?

Top comments (0)