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, ovvero 9,3 sulla più recente scala 4.0. Sono corrette in Cursor 3.0, uscito il 2 aprile 2026, e ogni versione precedente risulta colpita.

Al momento della divulgazione non risultava alcuno sfruttamento attivo. La strada verso la correzione non è stata liscia. Cato ha segnalato il problema il 19 febbraio, il produttore lo ha respinto una prima volta il 23 febbraio, poi ha riaperto il caso, ha rilasciato una correzione il 1º aprile e la seconda il 1º giugno. I numeri CVE sono stati assegnati il 5 giugno.

Come una pagina web diventa un comando

La tecnica è la prompt injection senza alcun clic. Lo sviluppatore non digita mai un ordine dannoso. È l'agente a leggere contenuti per conto dell'utente: la risposta di un server Model Context Protocol collegato, una pagina restituita da una ricerca sul web oppure un file interno al progetto. Quel contenuto porta con sé ordini nascosti, ai quali il modello finisce per obbedire.

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 alcun controllo. Un'istruzione iniettata può così sovrascrivere un file di sistema, come il binario di supporto della sandbox o un profilo della shell. La seconda falla sfrutta un controllo dei collegamenti simbolici che in caso di errore lascia passare: quando Cursor non riesce a risolvere un collegamento, si fida del percorso interno al progetto e scrive dritto sullo stesso programma di supporto. Sovrascritto quel programma, il comando successivo gira fuori dalla sandbox con tutti i diritti dello sviluppatore.

La lista di lettura è ora la superficie di attacco

Lo spostamento scomodo riguarda ciò che conta come input. Per anni il modello di minaccia di un editor di codice era il codice che si scriveva e le estensioni che si installavano. Un agente autonomo lo allarga a tutto ciò che legge da solo: il README di una dipendenza, la risposta di uno strumento, una pagina scaricata. Ognuno di questi elementi è oggi istruzione eseguibile, e il raggio d'azione è il sistema operativo invece di una scheda del browser.

Per un'azienda che ha distribuito assistenti di programmazione ai propri ingegneri, lo strumento diventa un componente della catena di fornitura con portata fino alla macchina, non un plugin di produttività. Con NIS2 nell'UE, e con gli obblighi equivalenti che le imprese britanniche già sostengono, la sicurezza del software consegnato al personale è responsabilità del consiglio di amministrazione, e un agente non aggiornato che si fida di contenuti non verificati ricade in pieno in quel dovere.

Cosa dovrebbero fare i titolari questa settimana

Il passo immediato è l'igiene delle versioni. Occorre verificare che ogni sviluppatore usi Cursor 3.0 o successivo, perché nulla di precedente è sicuro, e porre la stessa domanda per ogni altro editor con agente o assistente IDE in uso. Va poi chiarito quali strumenti di 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. Conviene limitare quali server Model Context Protocol un team può collegare, tenere gli agenti lontani dai contenuti esterni non rivisti dove possibile ed esigere l'approvazione umana per le scritture fuori dal progetto di lavoro. Lo strumento merita di restare. I permessi che lo circondano richiedono ora la stessa disciplina che già si applica a qualsiasi componente in grado di toccare una macchina in produzione.

Da leggere ora: Un'IA ha condotto da sola un intero attacco ransomware  |  Un difetto Squid di 29 anni espone i login in chiaro