Skip to main content
CursorкибербезопасностьAI automation

Cursor непомітно запускає чужий код з репозиторію

Mindgard публічно розкрила zero-day в Cursor для Windows: IDE може непомітно запустити шкідливий git.exe з папки проекту без попереджень. Для бізнесу це критично, оскільки це ламає базову модель довіри в інтеграції ШІ та підвищує ризик компрометації робочих станцій розробників. Це тривожний дзвінок.

Технічний контекст

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

Саме на таких історіях я зазвичай перевіряю зрілість впровадження ШІ в компанії. Якщо інструмент для розробки ламається на пошуку бінарника в робочому середовищі, проблема вже не в моделі й не в агенті, а в базовій гігієні продукту.

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

Мене тут зачепило не тільки саме виконання коду, а тиша навколо нього. Немає попередження, немає підтвердження, навіть натяку, що IDE зараз чіпає бінарник із недовіреного репозиторію.

Історія ще гірша через таймінг. Mindgard повідомляє, що надіслала звіт 15 грудня 2025 року, потім пінгувала повторно, включаючи HackerOne, а вразливість залишалася відтворюваною щонайменше у версії 3.2.16, перевіреній 30 квітня 2026 року. Якщо цифри правильні, це понад шість місяців і 197+ релізів без фіксу.

На сьогодні, 15 липня 2026 року, новина вже не свіжа у форматі «щойно знайшли», а скоріше показовий розбір того, як повне розкриття стає останнім захистом, коли вендор тягне. Cursor казав Dark Reading, що проблему «вирішують», але сам факт публічного розкриття вже багато говорить про процес реагування.

Що це змінює для бізнесу та автоматизації

Програють команди, які відкривають зовнішні репозиторії на бойових Windows-машинах розробників без ізоляції. Виграють ті, хто давно розділив довірені та недовірені середовища, а запуск AI-автоматизації та інструментів розробки тримає всередині політикових контурів.

Практичний висновок у мене простий: будь-які AI IDE та агенти треба включати в ту саму модель загроз, що й браузер, пошту та RDP-клієнт. Якщо розробник тягне код ззовні, йому потрібен sandbox, а на Windows хоча б AppLocker або Windows App Control.

І так, це б’є не тільки по безпеці, а й по архітектурі процесів. Я б переглядав, де саме у вас живе інтеграція ШІ для розробки, хто має право відкривати зовнішні проекти локально і які бінарники взагалі можуть стартувати з робочого середовища.

Якщо у вас команда вже зав’язана на Cursor, Copilot, агентах і внутрішніх тулах, я б не чекав наступної такої історії. В Nahornyi AI Lab ми якраз допомагаємо вибудувати AI-автоматизацію та захисні обмеження так, щоб розробники не втрачали швидкість, а бізнес не платив за одну невдало відкриту папку. Якщо хочете, розберемо ваш контур разом і зберемо нормальну схему без зайвої магії.

Ми вже розбирали, як атаки через омогліфи Unicode обманюють ШІ-агентів і змушують їх виконувати шкідливі команди. Ця загроза безпосередньо перегукується з виявленою вразливістю в Cursor, де зловмисник може отримати повний контроль над редактором.

Поділитися статтею