Vulnerabilità critica in Cursor: aprire un repository Git può eseguire codice malevolo su Windows senza alcun intervento

Attenzione immediata: se utilizzi Cursor su Windows, non aprire repository Git sconosciuti o non verificati sul tuo sistema operativo principale. La soluzione rapida è usare Windows Sandbox o una macchina virtuale isolata per testare progetti esterni. Questa guida spiega in modo chiaro cosa sta accadendo, perché è pericoloso e come proteggerti subito, anche senza aggiornamenti dal produttore.

Cursor è un editor di codice potenziato dall’intelligenza artificiale, utilizzato da oltre 7 milioni di sviluppatori. Tuttavia, una vulnerabilità critica e ancora non corretta permette a un attaccante di eseguire qualsiasi programma sul tuo computer Windows semplicemente creando un repository Git compromesso. Non serve cliccare, non serve confermare, non serve alcun avviso: l’azione avviene automaticamente quando si apre il progetto. Il file malevolo, chiamato git.exe, viene eseguito con i stessi privilegi del tuo account utente, consentendo l’installazione di ransomware, l’acquisizione di credenziali o il monitoraggio silenzioso delle tue attività.

La falla è stata scoperta il 15 dicembre 2025 dall’azienda di sicurezza Mindgard, che ha segnalato il problema al team di Cursor. Nonostante 197 aggiornamenti successivi, la vulnerabilità è ancora presente nella versione più recente testata (3.2.16). Dopo sette mesi di silenzio dal produttore, Mindgard ha deciso di pubblicare pubblicamente tutti i dettagli tecnici per proteggere gli utenti. Non esiste ancora un patch ufficiale, quindi la protezione dipende da misure compensative come regole di blocco basate su percorso o isolamento in ambienti sandbox.

Perché è così pericoloso?

Il problema nasce dal modo in cui Cursor cerca i file relativi a Git quando carica un progetto. Uno dei percorsi esaminati è proprio la radice del workspace (la directory principale del progetto). Se un attaccante inserisce un file chiamato git.exe in quella posizione, Cursor lo esegue automaticamente come parte del suo processo normale di risoluzione dei percorsi.

Durante i test, Mindgard ha usato una copia rinominata del Calcolatore di Windows come dimostrazione innocua. Appena il progetto è stato aperto in Cursor, il sistema ha eseguito ripetutamente il file, generando molteplici istanze del Calcolatore. Questo comportamento è confermato dai log di Sysinternals Process Monitor, che mostrano come Cursor.exe abbia avviato il file inserito tramite una query standard git rev-parse --show-toplevel.

In un attacco reale, il file git.exe non sarebbe il Calcolatore, ma un malware attivo: un loader di ransomware, un raccoglitore di credenziali o un keylogger. Operando silenziosamente con i privilegi del tuo account, il malware potrebbe compromettere completamente il tuo sistema, accedere a dati sensibili o diffondersi alla rete aziendale.

Come si è svolta la comunicazione con il produttore

Mindgard ha seguito i protocolli standard di divulgazione coordinata:

• 15 dicembre 2025: Prima segnalazione tramite l’email pubblicata nel file security.txt di Cursor, con richieste ripetute di stato.
• Jan 2026: Dopo nessun riscontro, Mindgard ha contattato pubblicamente Cursor su LinkedIn. Il CISO di Cursor ha risposto, attribuendo il ritardo a un errore di automazione su HackerOne, e ha invitato Mindgard nel programma privato di bounty.
• Valutazione del bounty: La segnalazione è inizialmente chiusa come “Informativa” e fuori scope. Solo dopo che Mindgard ha contestato la decisione e gli staff di triage di HackerOne hanno riprodotto il bug, la classificazione è stata invertita.
• Jan – Jun 2026: Mindgard ha inviato molteplici richieste di stato tramite HackerOne e ha tentato di contattare direttamente i dirigenti di Cursor. Nessun messaggio è stato risposto, mentre il produttore ha continuato a rilasciare decine di nuove versioni.

Questo ritardo prolungato nel gestire vulnerabilità critiche negli ambienti di sviluppo riflette preoccupazioni più ampie nel settore sulla compromissione dei dispositivi degli sviluppatori tramite script di terze parti non sicuri.

Misure di protezione immediate

Poiché non esiste un patch ufficiale, gli utenti devono adottare controlli di sicurezza compensativi:

Per organizzazioni e ambienti enterprise

• Regole di blocco basate su percorso: Utilizza AppLocker o Windows App Control per creare regole di blocco che mirano alle directory dei workspace (es. %USERPROFILE%\source\repos*\git.exe). Poiché i binari forniti dall’attaccante variano in hash, le regole devono bloccare il percorso del file, non la firma.
• Integrazione EDR: Windows non ha bloccaggio nativo di applicazioni aware del processo padre. Per una mitigazione completa, configura override delle regole EDR per monitorare i processi figli di Cursor.exe.

Per sviluppatori individuali

• Isolamento sandbox: Non aprire repository non verificati o nuovi direttamente sul sistema operativo host. Apri i progetti esclusivamente in una Virtual Machine (VM) disposable o in una sessione Windows Sandbox fino all’arrivo di un patch formale.
• Audit dei processi: Monitora i task manager attivi per processi figli non autorizzati. I team di sicurezza dovrebbero auditare proattivamente gli endpoint per difendersi da livelli di esecuzione non verificati che potrebbero bypassare l’isolamento host tradizionale.

Technical Deep Dive

Analisi tecnica della vulnerabilità

La vulnerabilità è legata alla risoluzione dei binari Git durante l’apertura di un progetto di sviluppo in Cursor. Cursor cerca i binari Git in diversi percorsi, incluso il workspace root. Se un attaccante posiziona un file malevolo chiamato git.exe in questa directory, Cursor lo esegue automaticamente come parte della sua routine di risoluzione dei percorsi.

Meccanismo di esecuzione:

• Cursor esegue implicitamente la ricerca senza prompt di sicurezza o avvisi all’utente.
• Il processo padre Cursor.exe avvia il binario inserito tramite una query standard git rev-parse --show-toplevel.
• Il binario viene eseguito con i privilegi dell’utente loggato, consentendo azioni arbitrarie.

Verifica tecnica:

• Log di Sysinternals Process Monitor confermano l’avvio del binario da Cursor.exe.
• La vulnerabilità è stata verificata sulla versione 3.2.16 di Cursor.
• Mindgard ha dimostrato il comportamento con una copia rinominata di calc.exe (Calcolatore Windows) come proof-of-concept innocuo.

Implicazioni di sicurezza

In scenari reali, il file git.exe sarebbe sostituito da:

• Loader di ransomware
• Raccoglitori di credenziali
• Keylogger silenziosi

Questi malware operano sotto il livello di privilegio corrente dell’utente, bypassando molte protezioni tradizionali.

Strategie di mitigazione avanzate

1. Regole AppLocker basate su percorso:

   %USERPROFILE%\source\repos*\git.exe
   

   Blocca tutti i file git.exe nelle directory dei workspace, indipendentemente dall’hash.

2. Configurazione EDR:

   • Monitora i processi figli di Cursor.exe.
   • Implementa override delle regole per bloccare l’avvio di binari non autorizzati da directory di workspace.

3. Isolamento sandbox:

   • Usa Windows Sandbox o VM disposable per repository non verificati.
   • Evita l’apertura diretta sul sistema host.

4. Audit dei processi:

   • Monitora i task manager per processi figli non autorizzati.
   • Audit proattivo degli endpoint per identificare livelli di esecuzione non verificati.

Conclusione tecnica

La vulnerabilità rappresenta un rischio significativo per la sicurezza degli ambienti di sviluppo, poiché permette l’esecuzione di codice arbitrario senza interazione dell’utente. La mancanza di un patch ufficiale rende fondamentale l’adozione di misure compensative per limitare l’esposizione. Gli sviluppatori e le organizzazioni devono agire immediatamente per proteggere i loro sistemi.

Fonte: https://cybersecuritynews.com/critical-cursor-0-day-flaw/