L'ombreggiamento locale dei binari trasforma una semplice apertura di repo in un rischio per Windows

Negli strumenti per sviluppatori, il momento pericoloso non è sempre un pulsante etichettato "esegui". A volte è il passaggio più silenzioso: aprire una cartella che sembra normale, ma contiene un binario con un nome familiare. Il caso dell'IDE Cursor rientra in questo schema. La preoccupazione di sicurezza non riguarda attacchi di prompt ingegnosi o una risposta fuori controllo del modello. Riguarda la possibilità che Windows venga indotto ad avviare un eseguibile locale del repository quando l'utente intendeva solo ispezionare il codice.

Fatti rapidi

• Il problema segnalato riguarda Cursor IDE su Windows.
• L'apertura di un repository non attendibile potrebbe portare all'esecuzione arbitraria di codice.
• Il comportamento descritto non richiede prompt injection, interazione con un agente AI o ulteriori approvazioni da parte dell'utente.
• L'attenzione iniziale era rivolta a un git.exe malevolo, con successiva estensione dell'attenzione ad altri binari di supporto come hatch.exe in specifiche condizioni di progetto.
• Il comportamento di creazione dei processi in Windows può diventare rischioso quando il software avvia comandi usando solo il nome, invece di un percorso completo.

Come funziona la trappola

Il modello tecnico qui è l'ombreggiamento dei binari. Su Windows, se un programma chiede al sistema operativo di avviare un eseguibile senza fornire il percorso completo, il sistema può cercare in diverse posizioni prima di arrivare allo strumento previsto. Microsoft documenta che questa ricerca può includere la directory dell'applicazione e la directory corrente. Questo diventa rilevante quando la directory corrente è il repository stesso.

Dal punto di vista difensivo, la domanda chiave è se Cursor o un componente di supporto correlato possa essere indotto a invocare un comando attendibile usando solo il nome. Se un repository contiene un eseguibile con lo stesso nome, il file locale può essere selezionato al posto del binario di sistema previsto. In tal caso, l'apertura della cartella può diventare il trigger per l'esecuzione di codice.

Non si tratta della stessa cosa della prompt injection. Non dipende nemmeno dal fatto che un agente AI decida di eseguire istruzioni arbitrarie. Il rischio si colloca più in basso nello stack, nel confine tra l'editor, la directory del progetto e la risoluzione dei processi in Windows.

La documentazione di sicurezza di Cursor indica che Workspace Trust è disabilitato per impostazione predefinita, il che può ampliare l'esposizione quando gli utenti aprono cartelle sconosciute. Questo non prova di per sé una compromissione, ma aiuta a spiegare perché i flussi di lavoro di apertura dei repository meritino lo stesso livello di controllo delle azioni di esecuzione esplicite. Anche Git per Windows ha documentato uno schema simile di hijack della directory corrente, dimostrando che questa classe di bug non è nuova, anche se il prodotto lo è.

La lezione più ampia è semplice: la comodità dello sviluppo e la fiducia negli eseguibili possono entrare rapidamente in conflitto. Se le toolchain avviano componenti di supporto senza percorsi completamente qualificati, un repository può contenere più del solo codice sorgente. Può contenere un payload eseguibile mascherato da normale file di progetto.

Le informazioni disponibili supportano un'analisi del rischio, non un'affermazione definitiva su ogni versione, ogni disposizione del repository o qualsiasi impatto a valle confermato. Questa cautela è importante, ma lo è anche il segnale d'allarme: negli ambienti di sviluppo Windows, "aprire" a volte può significare "eseguire".

Conclusione

Gli editor assistiti dall'AI non eliminano i vecchi rischi del sistema operativo. Possono ereditarli. Questo caso ricorda che il confine di fiducia inizia prima che il codice venga compilato, prima che a un agente venga fornito un prompt e, a volte, persino prima che venga letta la prima riga. Per chi difende, l'assunzione più sicura è che i repository non attendibili siano contenuto attivo, non testo passivo.

WIKICROOK

• Ombreggiamento dei binari: Una tecnica in cui un eseguibile malevolo usa lo stesso nome di uno strumento affidabile, così il sistema operativo può eseguire per primo il file dell'attaccante.
• Workspace Trust: Una funzione di sicurezza che limita le azioni rischiose in cartelle o progetti non attendibili.
• Esecuzione arbitraria di codice: Una condizione in cui un attaccante può eseguire codice su un sistema bersaglio.
• Ordine di ricerca nella creazione dei processi: La sequenza che Windows usa per individuare un eseguibile quando viene fornito solo il suo nome.
• Hijack della directory corrente: Uno schema di attacco in cui un programma carica o esegue per errore un file dalla cartella di lavoro invece che da una posizione attendibile.