CVE-2026-63093: vulnerabilita zero-click su Cursor
Immagina di aprire un semplice progetto su Cursor, l’editor di codice potenziato dall’AI che milioni di sviluppatori usano ogni giorno. Nessun click sospetto, nessun download strano, nessuna richiesta di permessi. Eppure, in quel preciso istante, un codice malevolo potrebbe già essere in esecuzione sul tuo computer. Questo è esattamente lo scenario descritto da CVE-2026-63093, una vulnerabilità che sta facendo discutere la community della sicurezza informatica non tanto per il bug in sé, quanto per quello che rivela su come sono progettati gli IDE moderni.
In questo articolo analizziamo nel dettaglio questa vulnerabilità critica, capiamo perché non si tratta di un semplice errore da correggere con una patch, e vediamo quali sono le implicazioni per chi sviluppa software ogni giorno.
Cos’è CVE-2026-63093 e perché è pericolosa
CVE-2026-63093 è classificata come vulnerabilità di tipo binary planting, conosciuta anche come untrusted search path. In parole semplici: quando apri un repository su Cursor, l’IDE cerca automaticamente di eseguire alcuni eseguibili, come git.exe, partendo dalla directory principale del progetto stesso.
Il problema? Se un attaccante inserisce un file git.exe malevolo nella root del repository e riesce a farti aprire quel progetto, il codice dannoso viene eseguito automaticamente, con gli stessi privilegi del tuo utente. Non serve cliccare su nulla. Non serve autorizzare nulla. Questo tipo di attacco viene definito zero-click proprio perché non richiede alcuna interazione da parte della vittima.
La vulnerabilità è stata scoperta e segnalata privatamente da Mindgard il 15 dicembre 2025, per poi essere divulgata pubblicamente il 14 luglio 2026. NVD ha pubblicato la CVE ufficiale nello stesso mese, confermando la gravità del problema.
Il meccanismo tecnico: come funziona l’attacco su Windows
Per capire davvero la portata del problema, bisogna guardare a come Windows gestisce la ricerca degli eseguibili. Quando un’applicazione chiama un comando come “git” senza specificare un percorso assoluto, il sistema operativo cerca quel file seguendo un ordine preciso di directory.
Il punto critico è questo: la working directory corrente (cioè la cartella del progetto aperto) viene spesso controllata prima delle directory di sistema più sicure, come System32. Questo significa che se l’IDE lancia “git.exe” senza specificare dove si trova esattamente, Windows potrebbe trovare ed eseguire un file malevolo posizionato proprio nella cartella del repository.
Ecco perché parliamo di attacco architetturale e non di un semplice bug isolato:
- Non è un problema legato a una singola stringa di codice o a un percorso specifico
- È la logica stessa di risoluzione dei binari a creare la falla
- Qualsiasi file eseguibile piazzato nella root del progetto può sfruttare questo meccanismo
- L’attacco funziona anche con file di configurazione che invocano automaticamente strumenti esterni
Perché non basta bloccare “git.exe”
Un errore comune nell’affrontare questa vulnerabilità sarebbe pensare: “basta impedire l’esecuzione di git.exe dalla root del progetto e il problema è risolto”. Purtroppo la realtà è molto più complessa.
Il vero problema è generalizzabile a qualsiasi binario risolto per nome all’interno della directory del progetto. Non importa se si chiama git.exe, hatch.exe o qualsiasi altro strumento: se l’IDE lo cerca senza specificare un percorso assoluto, il rischio rimane identico.
Esistono inoltre dei cosiddetti trigger stealth, ovvero file di configurazione del progetto (come pyproject.toml o tasks.json) che possono indurre l’IDE a invocare automaticamente strumenti esterni senza che l’utente se ne accorga. Questo rende inutile qualsiasi strategia di difesa basata su blacklist di nomi file specifici.
Il fallimento del Workspace Trust
Molti IDE moderni implementano una funzionalità chiamata Workspace Trust, pensata proprio per proteggere gli utenti da repository non fidati. Ma quanto è efficace davvero in questo caso?
Nel caso specifico di Cursor, la documentazione ufficiale rivela un dettaglio fondamentale: Workspace Trust è disattivato di default. Questo significa che, aprendo un qualsiasi repository, il progetto viene automaticamente considerato “fidato” senza alcun intervento da parte dell’utente.
Ma anche quando questa funzionalità viene attivata manualmente, in molte implementazioni il gating non avviene prima della risoluzione dei binari. In pratica, l’IDE potrebbe già aver effettuato chiamate di sistema o avviato processi prima ancora che l’utente abbia confermato di fidarsi del workspace.
Questo ci porta a una conclusione importante: una protezione disattivata di default, o che non blocca le operazioni critiche prima che avvengano, non è una protezione reale.
Come proteggersi: raccomandazioni pratiche
Data la complessità del problema, servono contromisure sia a livello di singolo utente che di organizzazione. Ecco una serie di azioni concrete da adottare.
Per sviluppatori e team
- Non aprire mai repository non verificati sulla macchina di lavoro principale. Usa macchine virtuali, container o ambienti sandbox per ispezionare codice sconosciuto prima di aprirlo nell’IDE principale
- Attiva Workspace Trust manualmente nelle impostazioni, anche sapendo che non è una soluzione completa
- Disabilita le automazioni automatiche, come l’esecuzione di task all’apertura del progetto
- Controlla la variabile PATH del sistema, evitando di includere la directory corrente o cartelle di progetto in contesti sensibili
Per chi sviluppa strumenti e IDE
- Non risolvere né eseguire binari dal workspace senza un consenso esplicito e preventivo dell’utente
- Utilizzare sempre percorsi assoluti per gli strumenti esterni, invece di affidarsi alla ricerca implicita del sistema operativo
- Implementare controlli di integrità e firma digitale per i runtime esterni utilizzati
- Rivedere le impostazioni di default, privilegiando la sicurezza rispetto alla comodità immediata
Il vero problema architetturale da risolvere
Il punto centrale di tutta questa vicenda non riguarda un singolo file o una singola funzione da correggere. Il problema di fondo è che gli IDE moderni, nel tentativo di offrire un’esperienza fluida e automatizzata, finiscono per attraversare il confine tra contenuto non fidato ed esecuzione di codice senza adeguate barriere di controllo.
Finché il modello di difesa rimane ancorato all’idea di “bloccare il singolo file pericoloso” invece di proteggere strutturalmente questo confine critico, continueremo a vedere nuove varianti dello stesso tipo di attacco: cambieranno i nomi dei binari coinvolti, cambieranno i trigger nei file di configurazione, ma la logica di fondo resterà identica.
Conclusione
CVE-2026-63093 rappresenta molto più di un semplice bug da correggere con un aggiornamento. È il sintomo di una debolezza architetturale più profonda che riguarda il modo in cui gli editor di codice moderni gestiscono l’esecuzione automatica di eseguibili esterni.
La lezione principale da trarre è questa: la sicurezza informatica negli strumenti di sviluppo non può basarsi su liste di file da bloccare o su funzionalità di protezione disattivate di default. Serve un cambio di paradigma che metta al centro il controllo rigoroso del confine tra codice non fidato ed esecuzione effettiva sul sistema.
Nel frattempo, la raccomandazione pratica per ogni sviluppatore resta chiara: tratta ogni repository sconosciuto come potenzialmente pericoloso, usa ambienti isolati per l’ispezione preliminare del codice, e mantieni sempre attive tutte le protezioni disponibili, sapendo però che nessuna di esse, da sola, è sufficiente a garantire una sicurezza completa.