Gli assistenti di programmazione basati sull'intelligenza artificiale sono ormai parte stabile degli strumenti di lavoro degli sviluppatori, ma la loro superficie di attacco resta poco compresa. Lo dimostra DuneSlide, la coppia di vulnerabilità critiche scoperta dai ricercatori di Cato AI Labs in Cursor, l'editor di codice con AI che — secondo la stessa società produttrice — è usato da oltre metà delle aziende della classifica Fortune 500. Le due falle, CVE-2026-50548 e CVE-2026-50549, hanno entrambe punteggio CVSS 9.8 (9.3 nella scala 4.0) e condividono lo stesso esito: l'esecuzione di comandi arbitrari sulla macchina dello sviluppatore a partire da un singolo prompt, senza alcun clic né finestra di conferma da ignorare.

Come funziona l'attacco

A partire dalla serie 2.x, Cursor esegue di default i comandi da terminale generati dal suo agente AI dentro una sandbox, un recinto che limita ciò che quei comandi possono toccare così che un'istruzione anomala non possa danneggiare la macchina. DuneSlide serve proprio a evadere da quel recinto, e la via d'ingresso è la prompt injection: l'attaccante non digita nulla dentro Cursor, ma nasconde istruzioni malevole in un contenuto che l'agente legge per conto dell'utente — la risposta di un connettore MCP (Model Context Protocol) o una pagina restituita da una ricerca web. Basta porre all'assistente una domanda normale: le istruzioni nascoste "salgono a bordo" e, poiché non serve alcuna conferma dell'utente, l'attacco è zero-click.

Entrambe le falle usano lo stesso schema: convincere l'agente a scrivere un file che non dovrebbe poter scrivere, e usare quella scrittura per disattivare la sandbox. La CVE-2026-50548 abusa del parametro opzionale working_directory dello strumento run_terminal_cmd: quando l'agente lo imposta su un percorso diverso da quello predefinito, Cursor aggiunge quel percorso alla lista dei file scrivibili senza fare domande. Le istruzioni iniettate lo puntano allora verso un file di sistema — per esempio lo stesso helper della sandbox, o file di avvio come ~/.zshrc — e i comandi successivi girano senza più alcun recinto. La CVE-2026-50549 sfrutta invece la logica di verifica dei collegamenti simbolici (symlink): prima di scrivere, Cursor risolve i collegamenti per confermare che la destinazione reale sia dentro il progetto; quando quel controllo fallisce — perché il bersaglio non esiste o perché l'attaccante toglie i permessi di lettura a una cartella del percorso — Cursor "si arrende" e si fida del percorso apparente, scrivendo comunque fuori dal progetto. Due porte diverse, stessa evasione.

Una volta neutralizzata la sandbox, il comando successivo viene eseguito con i privilegi dell'utente: controllo della macchina dello sviluppatore e accesso a tutti gli ambienti cloud e SaaS a cui l'editor è collegato. Tutto a partire da un prompt apparentemente innocuo.

Va detto con chiarezza: le correzioni ci sono già. Entrambi i bug sono risolti in Cursor 3.0, rilasciato il 2 aprile 2026, e sono affette tutte le versioni precedenti. Non risultano sfruttamenti in attacchi reali: Cato presenta il lavoro come ricerca, non come campagna in corso. Il percorso di divulgazione è però istruttivo — segnalato il 19 febbraio, in un primo momento respinto perché il modello di minaccia del prodotto "non copriva l'abuso dei server MCP", poi riaperto dopo l'escalation dei ricercatori e infine corretto nella 3.0. Gli identificativi CVE sono stati assegnati il 5 giugno.

Cosa significa per le aziende italiane

Il punto non è Cursor in sé, ma la categoria. Gli strumenti di AI coding si stanno diffondendo rapidamente nei team di sviluppo e nelle startup italiane, spesso adottati dal singolo sviluppatore senza una politica aziendale: è la classica shadow AI. Ma la macchina di uno sviluppatore è un bersaglio di alto valore: contiene codice sorgente, segreti, chiavi API, credenziali cloud e accesso alle pipeline CI/CD. Un'esecuzione di codice a partire da una pagina web avvelenata trasforma l'assistente di sviluppo in un potenziale vettore di compromissione dell'intera catena di rilascio del software.

C'è poi un aspetto strutturale che i responsabili della sicurezza dovrebbero interiorizzare: la prompt injection non è un singolo bug da correggere una volta per tutte, ma una classe di problemi che riemerge ogni volta che un agente AI legge contenuti non attendibili dal web o da connettori esterni. Cato stessa dichiara di stare divulgando falle analoghe in altri agenti di codice. Ogni connettore MCP aggiunto amplia la superficie di attacco: più l'agente è "connesso", più occasioni ha di leggere istruzioni ostili.

Il quadro normativo

Per i soggetti in perimetro NIS2, la sicurezza della catena di fornitura del software e delle pratiche di sviluppo rientra tra le misure di gestione del rischio richieste: strumenti di sviluppo non governati e non aggiornati sono un punto debole documentabile. Se sulle macchine di sviluppo transitano dati personali — non raro in ambienti di test mal isolati — una compromissione può inoltre configurare una violazione ai sensi del GDPR, con i relativi obblighi di notifica.

Cosa fare subito

  • Aggiornare Cursor alla versione 3.0 o successiva su tutte le postazioni.
  • Censire gli strumenti di AI coding effettivamente in uso in azienda, comprese le adozioni individuali non autorizzate.
  • Limitare i connettori MCP alle sole fonti fidate e disabilitare quelli non necessari.
  • Trattare ogni input dell'agente — pagine web, risposte di connettori, file di terzi — come potenzialmente ostile.
  • Applicare il minimo privilegio sulle macchine di sviluppo, tenere i segreti fuori dal codice in un gestore dedicato e monitorare il traffico in uscita per intercettare esfiltrazioni anomale.