14 липня Mindgard розкрила вразливість Cursor IDE для Windows: після відкриття репозиторію редактор може без додаткового запиту запустити файл git.exe із кореня проєкту. За даними дослідників, Cursor повторно викликає цей файл під час перевірки стану Git. Публічний тест востаннє підтверджено 30 квітня 2026 року на Cursor 3.2.16; на момент підготовки матеріалу Cursor не оприлюднила окремий advisory або перелік уражених версій.
Для атаки користувач спочатку має завантажити або клонувати репозиторій і відкрити його в Cursor на Windows. Якщо в корені проєкту є неочікуваний git.exe, таке відкриття слід розглядати як можливий запуск коду, а не як пасивний перегляд файлів.
Що підтвердила Mindgard, а що ще невідомо
| Факт | Практичне значення |
|---|---|
| Перевірена платформа | Windows із Cursor 3.2.16, останній тест — 30 квітня 2026 року. Звіт не підтверджує таку саму поведінку на macOS або Linux. |
| Умова запуску | У корені репозиторію міститься локальний git.exe, а користувач відкриває цей проєкт у Cursor. |
| Спостережена поведінка | Cursor запускав файл з аргументами Git і повторював виклик, доки проєкт залишався відкритим. |
| Статус виправлення | Під час розкриття Mindgard не мала інформації про remediation. Публічні security-сторінка та changelog Cursor станом на 15 липня не називали цей конкретний звіт. |
| Реальні атаки | Опубліковано proof of concept, але звіт не описує активну malware-кампанію з використанням цього шляху. |
Для безпечної демонстрації дослідники перейменували Windows Calculator на git.exe. Після відкриття репозиторію з’явилося кілька процесів Calculator. Шкідливий файл натомість міг би працювати як stealer, backdoor або loader із правами поточного користувача.
Як перевірити репозиторій до відкриття в Cursor
- Не запускайте Cursor. Спочатку перегляньте невідомий проєкт у File Explorer, text-only viewer або ізольованій віртуальній машині.
- Перевірте корінь репозиторію. Звичайному проєкту не потрібно постачати власний Windows-клієнт Git. Файл
git.exeпоруч ізREADME.md,package.jsonабо папками коду — причина зупинитися. - Не відкривайте файл подвійним кліком. Зафіксуйте назву, шлях, URL репозиторію та commit. Не завантажуйте весь приватний код у публічний scanner.
- Перевірте executable окремо. Зверніть увагу на цифровий підпис, властивості та hash. Невідомий або непідписаний файл із кореня завантаженого проєкту не слід дозволяти лише через назву Git.
- Використовуйте ізоляцію. Windows Sandbox або disposable VM відокремлює перевірку від browser sessions, SSH keys, cloud credentials і звичайних developer files.
У керованому середовищі можна протестувати AppLocker або App Control for Business, щоб заборонити запуск executables із каталогів розробки. Mindgard радить path-scoped правила, оскільки атакувальник може змінювати hash файла. Такі правила здатні ламати легітимні toolchains, тому спочатку використовуйте audit mode.
Що робити, якщо репозиторій уже відкривали
- Закрийте Cursor і припиніть роботу з проєктом. Не запускайте додаткові Git, package-manager, build або IDE команди.
- Від’єднайте ПК від мережі за наявності симптомів. Нові terminal windows, security alerts, outbound connections, невідомі процеси або повторні запуски потребують ізоляції.
- Збережіть докази. Запишіть URL репозиторію, commit hash, час завантаження, повний шлях і hash неочікуваного
git.exe. Не запускайте його повторно для перевірки. - Виконайте повне сканування. Security tool може видалити видимий executable, але loader, scheduled task, service, browser change або startup entry можуть залишитися. Видаліть detections, перезавантажте ПК і проскануйте ще раз, якщо активність повертається.
- Ротуйте developer secrets із чистого пристрою. Змініть GitHub/GitLab tokens, npm або PyPI publishing tokens, SSH keys, cloud API keys, signing credentials і робочі SSO sessions.
- Перевірте persistence та акаунти. Перегляньте Startup Apps, Task Scheduler, services, browser extensions, remote-access tools, recent sign-ins, нові OAuth apps і зміни в CI/CD.
- Замініть робочу копію. Після containment отримайте чистий репозиторій із перевіреного джерела та перегляньте його в ізоляції до повторного відкриття в IDE.
Перевірте ПК на malware, startup entries, scheduled tasks, services та інші persistence-компоненти. Видаліть detections, перезавантажте систему й повторіть scan, якщо активність повертається.
Подібні інциденти не завжди починаються з інсталятора. Матеріал про Deno RAT у фейкових завантаженнях пояснює відновлення developer accounts, а звіт про TrapDoor і poisoned AI-конфіги показує, чому файли репозиторію також є частиною attack surface.
Джерела
- Portnoy, Aaron / Mindgard. “Cursor 0day: When Full Disclosure Becomes the Only Protection Left.” Mindgard, опубліковано 14 липня 2026 року, дата доступу 15 липня 2026 року. Первинний звіт про вразливість.
- Cursor. “Security.” Cursor, оновлено 24 квітня 2026 року, дата доступу 15 липня 2026 року. Офіційна security-сторінка.
- Microsoft. “Install Windows Sandbox.” Microsoft Learn, оновлено 29 березня 2026 року, дата доступу 15 липня 2026 року. Інструкція з Windows Sandbox.
