Розробники та команди безпеки, які використовують популярний AI-редактор коду Cursor на операційній системі Windows, опинилися під загрозою. Дослідники безпеки виявили критичну логічну помилку в механізмі взаємодії редактора з утилітами контролю версій. Якщо користувач клонує та відкриває у Cursor сторонній репозиторій, що містить шкідливий файл з назвою git.exe у кореневому каталозі проєкту, редактор автоматично запустить його без жодних запитів, попереджень чи підтверджень з боку користувача.

Проблема полягає в тому, як саме Cursor намагається інтегруватися з Git на платформі Windows. Замість використання абсолютного шляху до системного або вбудованого бінарного файлу git.exe, середовище розробки виконує пошук утиліти, починаючи безпосередньо з робочої директорії (Current Working Directory). Таким чином, якщо у корні відкритої папки знаходиться файл з ім'ям git.exe, він отримує вищий пріоритет виконання, ніж легітимна системна утиліта Git, встановлена у системі.

Цей вектор атаки є надзвичайно небезпечним для розробників, які часто працюють з відкритим кодом або клонують публічні репозиторії з GitHub для аналізу. Для успішного виконання шкідливого коду зловмиснику не потрібно змушувати жертву запускати якісь скрипти чи компілювати проєкт. Достатньо лише того, щоб користувач відкрив папку з проєктом через інтерфейс Cursor. Одразу після імпорту папки редактор ініціює фонову перевірку статусу репозиторію і запускає локальний git.exe, що призводить до негайного компрометування робочої станції.

Оскільки Cursor працює в контексті поточного користувача, завантажений шкідливий файл отримує повний доступ до локальних ресурсів системи. Це дозволяє атакувальникам викрасти конфіденційні дані розробника: закриті SSH-ключі, токени доступу до хмарних платформ (наприклад, AWS, Google Cloud або Azure), файли конфігурації .env з паролями до баз даних, а також авторизаційні сесії для GitHub або GitLab. Ба більше, шкідливе програмне забезпечення продовжуватиме повторно запускатися та виконуватися у фоні протягом усього часу, поки проєкт залишається відкритим у редакторі.

Цей тип уразливості підкреслює зростаючі ризики використання сучасних AI-інструментів для розробки, які намагаються автоматизувати та спростити рутинні процеси, але при цьому нехтують базовими правилами безпеки операційних систем, такими як безпечний пошук виконуваних файлів (Safe DLL/Executable Search Order). Наразі розробникам радять бути максимально обережними при роботі з неперевіреними репозиторіями на Windows.

Що це означає на практиці

Для захисту робочих станцій розробників та запобігання витоку корпоративних секретів пентест-команда рекомендує вжити наступних заходів:

  • Тимчасово обмежити використання Cursor на Windows: До випуску офіційного патчу, який виправляє шлях пошуку системних утиліт, рекомендується використовувати альтернативні середовища розробки або запускати Cursor виключно всередині ізольованих контейнерів чи віртуальних машин (наприклад, через WSL2 або Windows Sandbox).
  • Перевіряти вміст репозиторіїв перед відкриттям: Перед тим як відкрити будь-який завантажений або клонований проєкт у Cursor, обов'язково перевіряйте його кореневу директорію на наявність підозрілих файлів, зокрема git.exe, git.cmd, git.bat або інших виконуваних файлів, яких там не повинно бути за логікою структури проєкту.
  • Налаштувати політики обмеження програмного забезпечення (AppLocker / WDAC): Впровадьте групові політики Windows AppLocker або Windows Defender Application Control, щоб заборонити запуск виконуваних файлів безпосередньо з каталогів завантажень розробників та папок проєктів (User-Writable Folders).
  • Провести аудит секретів та налаштувати ротацію: Переконайтеся, що на робочих станціях не зберігаються критичні API-ключі та паролі у відкритому вигляді. Налаштуйте регулярну ротацію SSH-ключів та використання короткочасних токенів доступу (OIDC) замість статичних облікових даних.
  • Моніторити дочірні процеси: Налаштуйте правила виявлення (наприклад, через Sysmon або EDR-системи), які відстежують запуск нетипових дочірніх процесів із процесу Cursor.exe, особливо тих, що запускаються з нестандартних шляхів або намагаються ініціювати мережеву активність до невідомих зовнішніх IP-адрес.