Se apri spesso progetti ricevuti da terzi, questa notizia merita attenzione: in alcune condizioni Cursor su Windows può eseguire automaticamente un file malevolo presente nel repository. La regola pratica è semplice: prima di aprire un progetto sconosciuto, controlla sempre che non contenga eseguibili nascosti o file sospetti.
La vulnerabilità riguarda il modo in cui l’IDE individua alcuni programmi di sistema necessari alle sue funzioni. Se nella cartella del progetto è presente un file con nome ingannevole, il programma può essere indotto a eseguirlo invece di usare una copia sicura del sistema. Il risultato è potenzialmente grave: il codice può partire con i privilegi dell’utente connesso, senza prompt aggiuntivi o passaggi di conferma.
Cosa è successo
Il problema nasce da una classica tecnica di binary planting, in cui un’applicazione cerca un eseguibile in più percorsi e finisce per affidarsi a quello trovato nel workspace prima di quello legittimo del sistema. Nel caso analizzato, il bersaglio era un file chiamato git.exe collocato alla radice del repository.
Quando Cursor apre un progetto, esegue controlli interni e comandi legati all’integrazione con Git, come la localizzazione della root del repository. Per farlo, cerca il binario necessario in varie posizioni, inclusa la cartella del progetto. Su Windows, l’ordine di ricerca dei programmi può favorire il file presente nella directory corrente rispetto a percorsi più affidabili.
Se un attaccante inserisce un git.exe malevolo nel repository e non esiste una copia lecita nello stesso percorso, il sistema può avviare quel file al posto dell’eseguibile autentico. In pratica, basta aprire la cartella perché il payload parta in automatico.
Perché è pericoloso
La particolarità di questa falla è che non richiede prompt injection, agent AI o interazione con modelli linguistici. Non serve neppure un accesso preliminare al computer della vittima. Il rischio nasce dal semplice fatto che il progetto contiene un file predisposto per essere eseguito nel momento in cui l’IDE tenta di fare introspezione sul repository.
Questo rende l’attacco difficile da intercettare con i controlli tradizionali. Molti team si concentrano su richieste sospette, contenuti testuali o prompt malevoli, ma qui il problema è più basilare: un file nel workspace viene trattato come se fosse affidabile.
Come si manifesta l’attacco
Il comportamento può essere dimostrato in modo semplice. In un test, è stato sufficiente rinominare un’applicazione Windows in git.exe e copiarla nella cartella del progetto. Aprendo il repository in Cursor, il binario veniva avviato automaticamente.
Il punto centrale è che il file non deve sembrare per forza un malware sofisticato. Può essere qualsiasi eseguibile capace di simulare un comportamento innocuo o di aprire una finestra di prova. Una volta eseguito, però, il payload può fare molto di più: installare componenti, leggere file locali, modificare dati del progetto o avviare altre azioni dannose.
Impatto sulla sicurezza
La gravità della falla è stata associata a esecuzione di codice arbitrario tramite un file malevolo nel repository. In termini pratici, il rischio è che un utente apra un progetto apparentemente normale e venga compromesso senza accorgersene.
Il problema non si limita al nome git.exe. Ricerche successive hanno mostrato che logiche simili di ricerca e avvio possono estendersi ad altri binari, ad esempio in presenza di file di configurazione che attivano percorsi differenti. Questo significa che difendersi controllando solo un singolo filename non basta.
Workspace Trust non basta da solo
Molti ambienti di sviluppo moderni includono una funzione chiamata Workspace Trust, pensata per ridurre i rischi nei progetti non attendibili. L’idea è corretta: limitare le azioni pericolose finché il contenuto non viene considerato sicuro.
Nella pratica, però, il semplice meccanismo di fiducia non elimina automaticamente tutti i percorsi di esecuzione. Se l’IDE continua a cercare un binario in un workspace non attendibile, e quel binario si trova proprio lì, il rischio resta presente.
Questo crea una lezione importante per i team di sicurezza: non basta bloccare le funzionalità visibili all’utente se il motore interno del programma continua a risolvere ed eseguire file dalla cartella aperta.
Altre superfici di attacco collegate
Questa vulnerabilità non è un caso isolato. Negli ultimi mesi sono emersi altri problemi che mostrano come gli IDE basati su tecnologie AI stiano diventando superfici di attacco sempre più ampie.
Tra i rischi più rilevanti ci sono:
- risoluzione di binari in cartelle non fidate;
- confini di trust troppo deboli tra workspace e sistema operativo;
- componenti embedded obsoleti ereditati da build non aggiornate;
- possibilità di esecuzione indesiderata tramite file di configurazione apparentemente innocui.
Il messaggio per i difensori è chiaro: l’attenzione non deve fermarsi al solo contenuto testuale del progetto. Anche la struttura del repository, i nomi dei file e i flussi interni dell’IDE possono trasformarsi in vettori di compromissione.
Cosa devono fare i developer
Per ridurre il rischio, conviene adottare alcune abitudini operative molto concrete:
- aprire solo repository provenienti da fonti note e verificate;
- controllare la presenza di eseguibili nella root del progetto;
- evitare di eseguire automaticamente build o script in workspace sconosciuti;
- usare account con privilegi minimi durante lo sviluppo;
- mantenere aggiornati IDE, estensioni e componenti di runtime;
- ispezionare con attenzione file come git.exe, hatch.exe e altri binari non attesi.
Anche i team SOC dovrebbero ampliare i controlli oltre il singolo nome di file. Filtrare solo su git.exe lascia scoperti altri percorsi equivalenti, quindi è meglio monitorare l’apertura di repository non fidati insieme all’avvio di processi inattesi dal workspace.
Cosa cambia per la sicurezza degli IDE
La vera barriera di sicurezza non è il nome del file, ma il passaggio da contenuto non fidato a codice eseguibile nel momento in cui una cartella viene aperta. Questa differenza è fondamentale per chi costruisce, difende o usa strumenti di sviluppo moderni.
In altre parole, un progetto deve essere trattato come un pacchetto potenzialmente eseguibile, non come una semplice raccolta di testo e configurazioni. Se un IDE può cercare file dinamicamente nel workspace, allora quel workspace va considerato una zona ad alto rischio fino a prova contraria.
Technical Deep Dive
La vulnerabilità sfrutta un classico problema di search-order hijacking su Windows, in cui la chiamata a un processo può risolvere l’eseguibile in percorsi non sicuri prima di arrivare alle directory di sistema. Nel caso descritto, Cursor tenta di individuare git.exe per eseguire operazioni di introspezione sul repository, tra cui comandi come git rev-parse --show-toplevel.
Il flusso tecnico è questo: l’IDE apre il workspace, attiva le routine di rilevamento del repository e invoca la creazione del processo tramite il meccanismo nativo del sistema operativo. Se la directory corrente o la root del progetto entrano nell’ordine di ricerca, un file malevolo collocato lì può essere selezionato prima dell’eseguibile legittimo installato nel sistema. L’esecuzione avviene con il token dell’utente corrente, quindi il danno dipende dai privilegi dell’account connesso.
La dimostrazione più chiara consiste nel sostituire l’eseguibile con un binario innocuo rinominato, ad esempio un’applicazione di sistema o un semplice loader. Se il programma parte all’apertura del progetto, il comportamento conferma che il problema non riguarda una specifica funzione AI, ma il modo in cui l’IDE affida al workspace la risoluzione di strumenti esterni.
Un aspetto rilevante è che il trigger non richiede un’azione esplicita dell’utente oltre all’apertura della cartella. Questo rende il vettore vicino a una forma di zero-click execution nel contesto dell’IDE, anche se la catena dipende sempre dalla presenza del file preparato dall’attaccante nel repository.
Le varianti osservate successivamente mostrano che la superficie non è limitata a Git. In alcuni casi l’IDE può cercare altri binari, come hatch.exe, quando trova file di configurazione specifici come pyproject.toml. In questi scenari, il file di configurazione non è il problema principale: funge da semplice attivatore che spinge l’applicazione a invocare un altro eseguibile dalla stessa area non fidata.
Dal punto di vista difensivo, il punto debole è la fiducia implicita nel workspace. Una mitigazione efficace richiede almeno tre livelli: evitare che la directory corrente partecipi alla risoluzione degli eseguibili, imporre percorsi assoluti per gli strumenti esterni e separare chiaramente il contenuto del repository dai binari autorizzati dal sistema.
Infine, il caso evidenzia un tema più ampio nei prodotti basati su Electron e su componenti Chromium: se il runtime embedded non viene aggiornato con regolarità, restano esposte anche vulnerabilità ereditate da versioni precedenti. Per questo, la sicurezza degli IDE moderni va valutata lungo tutta la catena: risoluzione dei binari, gestione della fiducia del workspace, componenti runtime e controlli sui file presenti nei progetti.
Fonte: https://cybersecuritynews.com/cursor-0-day-vulnerability/
