Отворете хранилище в Cursor под Windows и ако файл с име git.exe се намира в коренната папка на проекта, Cursor го изпълнява. Без щракване, без диалогов прозорец за одобрение, без предупреждение, че нещо в папката е на път да се изпълни.

Каквото и да прави този двоичен файл, той го прави от ваше име – с вашите сорс кодове, SSH ключове и облачни токени. Cursor продължава да го изпълнява многократно, докато проектът остава отворен.

Без инжектиране на подкана (prompt injection), без агент, без модел в цикъла и без предварителен достъп до машината: отварянето на папката е целият експлойт, а резултатът е произволно изпълнение на код като вписания потребител.

Фирмата за ИТ сигурност Mindgard докладва за грешката на Cursor на 15 декември 2025 г. и публикува пълни технически подробности във вторник, седем месеца по-късно. Все още няма пач, а Cursor не са публикували предупреждение за проблема.

Механизмът се описва с едно изречение. Cursor проверява няколко местоположения за двоичен файл на Git при зареждане на проект, като едно от тях е самият работен плот. Резултатите от Process Monitor в анализа показват как Cursor.exe стартира двоичния файл от корена на хранилището с команден ред git rev-parse --show-toplevel.

Това е същата проверка за корен на хранилище, която описва документацията на Microsoft VS Code. Дали Cursor търси в тези местоположения сам или предоставя на Windows неквалифициран git и оставя реда на търсене да избере файла, анализът не посочва.

Демонстрацията на концепцията (Proof of Concept) от Mindgard представлява Windows Calculator, преименуван на git.exe и качен в корена. Клонираш, отваряш, готово. Снимката на екрана показва как прозорците на Calculator се натрупват сами, докато проектът стои отворен.

Предварителното условие звучи като трудната част: двоичният файл на нападателя да се намира в корена на вашия проект. Но не е. Клонирането на непознато хранилище е начинът, по който двоичните файлове първоначално се озовават на диска, а разработчиците и техните агенти правят това постоянно. Нападателят не се нуждае от първоначална опорна точка. Това е разстоянието, което този бъг покрива: от хранилище, което всеки може да публикува, до код, работещ от ваше име.

Едно ограничение на доказателствата: най-новото потвърждение с дата от Mindgard е от 30 април 2026 г. срещу Cursor 3.2.16, а текущата версия е 3.11, доставена на 10 юли. Анализът твърди, че бъгът оцелява в най-новата тествана версия, но не я назовава.

Медията The Hacker News прегледа всички 33 препоръки за сигурност, публикувани от Cursor, и не откри запис за този проблем към 15 юли. Не е назначен CVE номер. Попитахме Cursor да посочи версия, която го коригира, и Mindgard – коя е последната тествана от тях версия. Тази история ще бъде актуализирана при получаване на отговор.

Тъй като няма пач, всяка опция по-долу е заобиколно решение (workaround). За управлявани компютърни паркове с Windows, Mindgard предлага правила за забрана в AppLocker или Windows App Control, които блокират изпълнимия файл по име и път под корените на работната област, по подобие на %USERPROFILE%\source\repos\*\filename.exe.

Правила за пътища, а не хешове; двоичните файлове на нападателите варират по хеш. Windows няма общо вградено правило, което блокира дъщерен процес само когато конкретен родителски процес го стартира, отбелязва фирмата, така че сигурността, съобразена с родителския процес, обикновено изисква EDR системи. За всички останали: отваряйте ненадеждни хранилища в разполагаема виртуална машина или в Windows Sandbox.

Комбинирайте го със съвета на Cymulate да проверявате клонираното хранилище или разопакования архив, преди да го отворите. Файлове като git.exe, npx.exe, node.exe и where.exe нямат място в корена на проект. Това, което се случи с доклада, е останалата част от историята.

Страницата за сигурност на Cursor твърди, че компанията признава "доклади за уязвимости в рамките на 5 работни дни". Първият съществен отговор за Mindgard дойде месец след декемврийския доклад от CISO на Cursor, който обясни, че автоматизация е пропуснала да покани фирмата в частната програма в HackerOne.

Повторно изпратеният доклад беше затворен на следващия ден като информативен и извън обхват, след което беше отворен отново, след като Mindgard възразиха и HackerOne го възпроизведоха. HackerOne потвърди доставката на 20 януари. След това: искания за актуализация през февруари, март и април, и никакъв отговор обратно.

Историята на предупрежденията на Cursor, съпоставена с времевата линия на Mindgard, показва, че процесът е работил за други изследователи, докато докладът на Mindgard е стоял без движение. На 13 февруари 2026 г. Cursor публикува GHSA-8pcm-8jpx-hv8r, бягство от пясъчник чрез Git-hook (CVE-2026-26268), докладвано от Novee под координирано разкриване и коригирано в Cursor 2.5. Три дни по-късно, на 16 февруари, Mindgard поиска актуализация по своя собствен доклад, свързан с Git. Нямаше отговор. Още две предупреждения от Cursor бяха изпратени на 14 юли, деня, в който се появи пълното разкриване.

"Пълното разкриване е ядрената опция при разкриването на уязвимости", пише Mindgard, запазвайки я за случаи, в които всеки друг път се е провалил. Авторът Аарон Портной прекара години от другата страна на тази дейност: той ръководеше Zero Day Initiative и изгради първите шест състезания Pwn2Own.

Същият бъг при трима други доставчици

Mindgard не е първата фирма, която открива това, и не е първата, която получава отговора на Cursor за него. През юни Cymulate публикува констатации за идентичен клас уязвимости в AI инструментите: под Windows няколко от тези инструменти извикват помощни изпълними файлове, използвайки реда на търсене по подразбиране, който проверява работната директория преди надеждните системни пътища.

GitHub Copilot CLI...