Cosa ha trovato Cato in Cursor

Cato AI Labs ha reso note due vulnerabilità critiche in Cursor, l'editor di codice con IA che secondo il produttore è usato da più della metà delle Fortune 500. Battezzate DuneSlide e registrate come CVE-2026-50548 e CVE-2026-50549, entrambe hanno un punteggio CVSS di 9,8 su 10, o 9,3 sulla più recente scala 4.0. Sono corrette in Cursor 3.0, uscito il 2 aprile 2026, e ogni versione precedente è colpita.

Nessuno sfruttamento attivo era registrato al momento della divulgazione. La strada verso la correzione non è stata liscia. Cato ha segnalato il problema il 19 febbraio, il produttore lo ha prima respinto il 23 febbraio, poi lo ha riaperto, ha rilasciato una correzione il 1 aprile e la seconda il 1 giugno, e i numeri CVE sono stati assegnati il 5 giugno.

Come una pagina web diventa un comando

La tecnica è l'iniezione di istruzioni senza alcun clic. Lo sviluppatore non digita mai un ordine dannoso. Al suo posto l'agente legge contenuti per conto dell'utente: una risposta da un server Model Context Protocol collegato, una pagina restituita da una ricerca o un file dentro il progetto. Quel contenuto porta ordini nascosti che il modello poi obbedisce.

La prima falla abusa del parametro working_directory. Quando l'agente lo imposta su un percorso diverso da quello predefinito, Cursor aggiunge quel percorso alla lista di scrittura consentita senza controllarlo, così un'istruzione iniettata può sovrascrivere un file di sistema come il binario aiutante della sandbox o un profilo della shell. La seconda falla sfrutta un controllo dei collegamenti simbolici che cede all'errore: quando Cursor non riesce a risolvere un collegamento, si fida del percorso dentro il progetto e scrive dritto sullo stesso aiutante. Sovrascrivi quell'aiutante e il comando successivo gira fuori dalla sandbox con tutti i diritti dello sviluppatore.

La lista di lettura e ora la superficie di attacco

Lo spostamento scomodo riguarda cosa conta come input. Per anni il modello di minaccia di un editor era il codice che scrivevi e le estensioni che installavi. Un agente autonomo lo allarga a tutto ciò che legge da solo: il README di una dipendenza, una risposta di strumento, una pagina scaricata. Ognuna di queste è ora istruzione eseguibile, e il raggio d'azione è il sistema operativo invece di una scheda del browser.

Per un'azienda che ha distribuito assistenti IA ai suoi ingegneri, questo trasforma lo strumento in un componente della catena di fornitura con portata fino alla macchina, non in un plugin di produttività. Sotto NIS2 nell'UE, recepita in Italia e affiancata dall'Agenzia per la Cybersicurezza Nazionale, la sicurezza del software che distribuisci al personale è responsabilità del consiglio, e un agente non aggiornato che si fida di contenuti non verificati ricade proprio in quel dovere.

Cosa dovrebbero fare i titolari questa settimana

Il passo immediato è l'igiene delle versioni. Verifica che ogni sviluppatore sia su Cursor 3.0 o successivo, perché nulla di precedente è sicuro, e poni la stessa domanda per ogni altro editor con agente o assistente IDE in uso. Chiarisci quali strumenti IA hanno il permesso autonomo di scrivere file o eseguire comandi, e chi lo ha approvato.

Il passo duraturo è trattare le fonti di lettura di un agente come non affidabili per impostazione predefinita. Limita quali server Model Context Protocol un team può collegare, tieni gli agenti lontani da contenuti esterni non rivisti dove puoi ed esigi l'approvazione umana per le scritture fuori dal progetto di lavoro. Lo strumento merita di restare; i permessi attorno ad esso ora richiedono la stessa disciplina che già applichi a ogni componente in grado di toccare una macchina in produzione.