Open een repository in Cursor op Windows en als een bestand met de naam git.exe zich in de hoofdmap van het project bevindt, voert Cursor het uit. Geen klik, geen goedkeuringsdialoogvenster, geen waarschuwing dat iets in de map op het punt staat te worden uitgevoerd.
Wat dat binaire bestand ook doet, het doet het zoals jij, met je bron, je SSH-sleutels en je cloudtokens. Cursor blijft het opnieuw uitvoeren zolang het project open blijft.
Geen snelle injectie, geen agent, geen model in de lus en geen voorafgaande toegang tot de machine: het openen van de map is de volledige exploit en het resultaat is het uitvoeren van willekeurige code als de ingelogde gebruiker.
AI-beveiligingsbedrijf Mindgard meldde de fout op 15 december 2025 aan Cursor en publiceerde dinsdag, zeven maanden later, de volledige technische details. Er is nog steeds geen patch en Cursor heeft geen advies voor dit probleem gepubliceerd.
Het mechanisme duurt ongeveer een zin. Cursor controleert verschillende locaties op een binair Git-bestand wanneer een project wordt geladen, en een daarvan is de werkruimte zelf. De uitvoer van Process Monitor in het artikel laat zien dat Cursor.exe het repo-root binaire bestand voortbrengt met de opdrachtregel git rev-parse –show-toplevel.
Dat is dezelfde repository-root-probe die in de VS Code-documenten van Microsoft wordt beschreven. Of Cursor die locaties zelf doorzoekt of Windows een ongekwalificeerde git overhandigt en de zoekvolgorde laat kiezen, staat niet in het artikel.
Mindgard’s proof of concept was Windows Calculator, omgedoopt tot git.exe, en toegewijd aan de root. Klonen, openen, klaar. De schermafbeelding laat zien dat Rekenmachinevensters zichzelf opstapelen terwijl het project open stond.
De voorwaarde klinkt als het moeilijkste gedeelte: het binaire bestand van een aanvaller, dat in de hoofdmap van uw project zit. Dat is het niet. Het klonen van de repository van een vreemde is de manier waarop binaire bestanden in de eerste plaats op schijf terechtkomen, en ontwikkelaars en hun agenten doen dit de hele dag. De aanvaller heeft om te beginnen geen voet aan de grond nodig. Dat is de afstand die deze bug aflegt: vanuit een repository kan iedereen publiceren naar code die net als jij draait.
Eén beperking op het bewijsmateriaal. Mindgard’s meest recente gedateerde bevestiging is 30 april 2026, tegen Cursor 3.2.16, en de huidige release is 3.11, verzonden op 10 juli. Het artikel zegt dat de bug overleeft in de nieuwste versie die werd getest, maar noemt die versie niet.
The Hacker News beoordeelde alle 33 beveiligingsadviezen die Cursor heeft gepubliceerd en vond vanaf 15 juli geen artikel over dit probleem. Er is geen CVE toegewezen. We hebben Cursor gevraagd om elke release te noemen die dit probleem oplost, en Mindgard, welke versie het voor het laatst heeft getest. Dit verhaal wordt bij elke reactie bijgewerkt.
Wat te doen
Er is geen patch, dus elke optie hieronder is een oplossing. Op beheerde Windows-parken stelt Mindgard AppLocker of Windows App Control voor om regels te weigeren die het uitvoerbare bestand blokkeren op naam en pad onder de hoofdmap van de werkruimte, in de trant van %USERPROFILE%sourcerepos*filename.exe.
Padregels, geen hashes; binaire bestanden van aanvallers variëren per hash. Windows heeft geen algemene ingebouwde regel die een onderliggend proces alleen blokkeert wanneer een specifieke ouder het start, merkt het bedrijf op, dus ouderbewuste handhaving betekent over het algemeen EDR. Alle anderen: open niet-vertrouwde opslagplaatsen in een wegwerpbare VM of Windows Sandbox.
Combineer het met het advies van Cymulate om een gekloonde repository of uitgepakt archief te controleren voordat je het opent. git.exe, npx.exe, node.exe en where.exe hebben niets te maken met de root van een project. Wat er met het rapport is gebeurd, is de rest van het verhaal.
Cursor’s beveiligingspagina zegt dat het bedrijf “kwetsbaarheidsrapporten binnen 5 werkdagen” erkent. Het eerste inhoudelijke antwoord van Mindgard kwam een maand na het rapport van december, van de CISO van Cursor, die uitlegde dat een automatisering er niet in was geslaagd het bedrijf uit te nodigen voor het particuliere HackerOne-programma.
Het opnieuw ingediende rapport werd de volgende dag gesloten omdat het informatief was en buiten de reikwijdte viel, en vervolgens heropend nadat Mindgard zich terugtrok, en HackerOne reproduceerde het. HackerOne bevestigde de levering op 20 januari. Daarna: updateverzoeken in februari, maart en april, en niets terug.
Het adviesrapport van Cursor, gelezen tegen de tijdlijn van Mindgard, laat zien dat het proces voor andere onderzoekers werkte terwijl het rapport van Mindgard lag. Op 13 februari 2026 publiceerde Cursor GHSA-8pcm-8jpx-hv8r, een Git-hook sandbox-ontsnapping (CVE-2026-26268), gerapporteerd door Novee onder gecoördineerde openbaarmaking en opgelost in Cursor 2.5. Drie dagen later, op 16 februari, vroeg Mindgard om een update van zijn eigen Git-gerelateerde rapport. Geen antwoord. Op 14 juli, de dag waarop de volledige openbaarmaking plaatsvond, gingen nog twee Cursor-adviezen uit.
“Volledige openbaarmaking is de nucleaire optie van het openbaar maken van kwetsbaarheden”, schreef Mindgard, en reserveerde dit voor gevallen waarin elk ander pad heeft gefaald. De auteur, Aaron Portnoy, heeft jaren aan de andere kant van dat vak gezeten: hij leidde het Zero Day Initiative en bouwde de eerste zes Pwn2Own-wedstrijden.
Dezelfde bug, drie andere leveranciers
Mindgard is niet het eerste bedrijf dat dit ontdekt, en niet de eerste die het antwoord van Cursor hierop krijgt. In juni publiceerde Cymulate bevindingen over dezelfde klasse in AI-tools: op Windows lossen verschillende van deze tools uitvoerbare helperbestanden op met behulp van de standaardzoekvolgorde, die de werkmap controleert vóór vertrouwde systeempaden.
GitHub Copilot CLI voerde een werkruimte git.exe uit bij het opstarten, voordat de map-vertrouwen-prompt zelfs maar werd getoond. Gemini CLI deed hetzelfde toen het vanuit de werkruimte werd gelanceerd. De Codex-desktopapp deed het in een geopende map, zoals Cursor.
Volgens Cymulate’s artikel van 4 juni had geen van deze leveranciers een oplossing geleverd. GitHub heeft zijn rapport beoordeeld en een premie betaald, waarna het naar laag is gedegradeerd. Google was het ermee eens dat de Gemini CLI-bevinding geldig was en bracht geen patch uit. OpenAI sloot het Codex-rapport af als Niet van toepassing, met de redenering dat een aanvaller die git.exe kan vervangen al systeemtoegang heeft. Dat was niet het gerapporteerde scenario. Cursor sloot Cymulate’s Cursor CLI-rapport acht dagen later af als informatief, op grond van het feit dat bevindingen die een kwaadaardig binair bestand vereisen “geen aanvalsvector hebben”.
Dat onderzoek heeft wel één oplossing opgeleverd. AWS heeft CVE-2026-10591 toegewezen voor zijn Kiro-bevinding, heeft Cymulate gecrediteerd en gepatcht in Kiro 0.11. Maar dat was een andere bug: een fout bij het schrijven van agentbestanden waardoor een vergiftigde .vscode/tasks.json automatisch kon worden uitgevoerd in een geopende map. Geen van de rapporten over binaire aanplantingen had er één opgeleverd.
De klasse dateert van vóór dit alles. Een onbetrouwbaar zoekpad is de zwakte; het plaatsen van een binair bestand waar de zoekopdracht het zal vinden, is de aanval. Windows controleert de huidige map vóór %PATH% en dat is wat Git Credential Manager Core in 2020 kapot maakte (CVE-2020-26233): een kwaadaardige git.exe op het hoogste niveau van een repository, uitgevoerd in plaats van de echte tijdens een recursieve kloon. Opgelost in GCM 2.0.289.
De PoC van Blaze Information Security heette destijds ook calc.exe, omgedoopt tot git.exe. Zes jaar later komt dezelfde truc terecht bij een IDE die het onderzoek voor je uitvoert zodra je de map opent.
Vier leveranciers hebben nu een binaire werkruimte te zien gekregen die zichzelf op Windows draait zodra een ontwikkelaar de tool naar een gekloonde opslagplaats verwijst. Twee besloten dat het helemaal geen kwetsbaarheid was; twee waren het erover eens dat dit zo was en hadden volgens Cymulate’s verslag van juni sowieso niets verzonden. De oproep ligt dus bij de verdedigers, en op Windows is het veilig om een gekloonde repository te behandelen als uitvoerbare inhoud, want dat is het ook.
