← Все статьи
Новости4 мин чтения

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

PoC Mindgard показал: Cursor 3.2.16 на Windows мог найти git.exe в корне непроверенного репозитория при открытии. Что доказано и как снизить риск.

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

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

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

Подключите модели для проверки контента с оплатой в рублях на provod.ai

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

Публично названная проверка относится к 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

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

provod.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-ФЗ · главная provod.ai