DuneSlide: Due vulnerabilità critiche RCE tramite prompt injection zero-click nell’IDE Cursor

TL;DR

Cato AI Labs ha rilevato due vulnerabilità critiche di esecuzione di codice remoto (RCE) in Cursor IDE, il popolare ambiente di sviluppo che, secondo Cursor, è utilizzato da oltre la metà delle Fortune 500. Entrambe le vulnerabilità RCE, che chiamiamo “DuneSlide”, hanno ottenuto un punteggio CVSS di 9,8 e comportano l’uscita dall’ambiente sandbox dell’IDE; allo stesso tempo, sono state assegnate agli ID CVE CVE-2026-50548 e CVE-2026-50549.

Insieme, queste vulnerabilità mostrano come il prompt injection possa andare oltre il livello LLM ed esporre vulnerabilità classiche nei percorsi di codice che in origine non erano considerati parte della superficie di attacco.

Sfruttare una di queste vulnerabilità critiche consente a un malintenzionato di sovrascrivere file di sistema essenziali (come il file binario cursorsandbox), trasformando comandi eseguiti in sandbox in RCE al di fuori di essa e comportando la completa compromissione del sistema sia sulla macchina host sia negli spazi di lavoro SaaS connessi.

Riepilogo esecutivo

• Vulnerabilità critiche rilevate: Cato AI Labs ha identificato due vulnerabilità distinte in Cursor IDE, portando a RCE non eseguiti in sandbox sulla macchina dell’utente.
• Scrittura di file arbitrari tramite prompt-injection zero-click: questi difetti dell’architettura indipendenti consentono agli autori delle minacce di avvalersi di prompt injection zero-click per scrivere file arbitrari sul sistema locale dello sviluppatore.
• Uscita dalla sandbox e RCE: sfruttando queste primitive, un malintenzionato può uscire dalla sandbox del terminale, ottenendo così l’RCE completo e la completa compromissione del sistema.
• Vettore di attacco zero-click: L’exploit non richiede privilegi utente precedenti né l’interazione specifica dell’utente: si attiva quando una vittima esegue un prompt innocuo che acquisisce involontariamente un payload controllato da un malintenzionato da una fonte non attendibile, come un server MCP o un risultato di ricerca web.

Panoramica tecnica

La sandbox di cursor e il vettore di attacco

Cursor 2.x è stato messo a disposizione con l’esecuzione automatica di comandi del terminale all’interno di una sandbox per impostazione predefinita, che opera senza richiedere l’approvazione dell’utente. Questa funzionalità è pensata per prevenire l’affaticamento da approvazione, impedendo al contempo agli autori delle minacce di convertire facilmente un semplice prompt injection in un RCE.

Prima vulnerabilità: manipolazione dei parametri della directory di lavoro

La prima vulnerabilità risiede nel modo in cui la sandbox struttura i propri confini di sicurezza in base ai parametri degli strumenti. Quando viene eseguito un comando in sandbox, Cursor crea una policy di sicurezza che consente di scrivere direttamente nella directory di lavoro corrente.

• Sebbene il comportamento predefinito preveda di impostare la directory di lavoro per l’esecuzione del comando in corrispondenza della radice del progetto, working_directory è un parametro facoltativo dello strumento run_terminal_cmd.
• Il difetto esiste poiché, quando l’LLM assegna un valore non predefinito a questo parametro, tale percorso viene aggiunto senza alcun controllo alla lista di scrittura consentita della sandbox.
• Un prompt injection (veicolato da una richiesta innocua del server MCP o un risultato web compromesso) può indurre l’LLM a impostare working_directory su un percorso controllato da un malintenzionato al di fuori dell’ambito del progetto.
• Scrivendo nell’eseguibile cursorsandbox (/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox), l’autore delle minacce si assicura che i comandi futuri vengano eseguiti senza restrizioni della sandbox; pertanto, le istruzioni future all’interno dello stesso prompt injection portano a un RCE esterno alla sandbox.
• Altri percorsi vulnerabili includono ~/.zshrc, ~/.zshenv o ~/Library/LaunchAgents.

In genere, un malintenzionato non è in grado di controllare la directory di lavoro di un’operazione eseguita in sandbox. Tuttavia, poiché i codificatori rappresentano elementi di software unici, in questa vulnerabilità un attacco di prompt injection costituisce una via di transito a quella parte del codice.

Seconda vulnerabilità: errore di Canonicalizzazione del Symlink

La seconda vulnerabilità è completamente indipendente dalla prima e riguarda casi limite nella risoluzione del percorso dei file di Cursor. Consente agli attori malevoli di bypassare le protezioni di scrittura fuori limite utilizzando collegamenti simbolici.

• Un prompt injection (tramite una richiesta innocua del server MCP o un risultato web compromesso) può indurre l’agente Cursor a creare un symlink all’interno della directory del progetto che punta a un file situato al di fuori della stessa directory.
• Per impostazione predefinita, l’Agente Cursor tenta di canonicalizzare i percorsi (risolvendo i symlink) al fine di determinare la loro posizione reale e verificare che siano situati all’interno della radice del progetto.
• A questo punto, la vulnerabilità si verifica perché la logica di canonicalizzazione contiene un fallback pericoloso: se la canonicalizzazione non va a buon fine (ad esempio quando il percorso non esiste o mancano permessi di lettura su una delle sue directory), Cursor torna a utilizzare il percorso originale del symlink all’interno della directory del progetto.
• Un malintenzionato può quindi creare un symlink di sola scrittura, costringendo così Cursor a ritenere che il percorso risolto sia il percorso del symlink anziché quello di destinazione. Ciò permette di aggirare il controllo che mira a confermare l’ubicazione non compresa nei limiti della destinazione finale, consentendo all’attore delle minacce di collegarsi nuovamente all’eseguibile cursorsandbox (/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox).
• Utilizzando lo strumento di scrittura, il malintenzionato sovrascrive tale file esterno mediante il symlink, neutralizzando la sandbox per i comandi successivi eseguiti nell’ambito dello stesso prompt injection e ottenendo l’RCE.

Nella maggior parte del software classico, un attore esterno non può creare symlink da remoto sulla macchina della vittima. In questo caso, un attacco di prompt injection ha trasformato l’agente Cursor in un ponte per operazioni tutt’altro che banali, destinate a causare la compromissione totale del sistema.

Divulgazione responsabile

Cato AI Labs crede nella sicurezza dell’ecosistema IA, perciò ha aderito alle pratiche standard di divulgazione responsabile per DuneSlide:

• 19 febbraio: le vulnerabilità sono state segnalate al team di Cursor.
• 23 febbraio: le vulnerabilità sono state respinte. La giustificazione: il modello di minaccia di Cursor non tiene conto dell’uso improprio del server MCP anche nei casi in cui il server MCP stesso rappresenti un’integrazione standard e innocua, come l’area di lavoro ufficiale di Linear.app.
• 26 febbraio: a causa della gravità dei problemi, la segnalazione è stata inoltrata direttamente al team di sicurezza di Cursor. Il team di sicurezza ha iniziato a classificare le vulnerabilità segnalate.
• 1° aprile: il team di Cursor ha confermato che la correzione della vulnerabilità della directory di lavoro sarà inclusa nel client Cursor 3.0 (rilasciato il 2 aprile).
• 1° giugno: il team di Cursor ha confermato che la correzione della vulnerabilità del target del link è stata altrettanto inclusa in Cursor 3.0.
• 5 giugno: gli ID CVE-2026-50548 e CVE-2026-50549 sono stati assegnati, confermando l’entità delle vulnerabilità.

Conclusioni

DuneSlide evidenzia i rischi architetturali specifici legati alla dotazione di ambienti di esecuzione autonoma dei comandi per gli LLM. Sebbene il sandboxing rappresenti una difesa necessaria, specifici difetti intrinseci alla validazione dei parametri e ai casi limite di risoluzione dei percorsi dimostrano che i prompt injection zero-click possono sfruttare lacune logiche a sé stanti per ottenere il controllo completo del sistema. Se questi problemi fossero stati casi isolati di compromissione tramite prompt injection, avremmo potuto attribuirli a vulnerabilità specifiche. Cato AI Labs, tuttavia, è in procinto di divulgare responsabilmente vulnerabilità in tutti i codificatori più diffusi, evidenziando l’importanza di un approccio maggiormente sistemico alla protezione. Continua a monitorare gli sviluppi.