Check Point Research ha scoperto una vulnerabilità di esecuzione di codice remoto persistente in Cursor, uno degli strumenti di codifica basati sull’IA a più rapida crescita utilizzati oggi dagli sviluppatori. Combina la modifica del codice locale con potenti integrazioni di modelli linguistici di grandi dimensioni (LLM) per aiutare i team a scrivere, eseguire il debug ed esplorare il codice in modo più efficiente. Ma questa profonda integrazione comporta una maggiore fiducia nei flussi di lavoro automatizzati e un aumento del rischio quando tale fiducia viene sfruttata.
La scoperta della vulnerabilità ad alto impatto nel sistema Model Context Protocol (MCP) di Cursor
Check Point Research ha deciso di valutare il modello di sicurezza alla base degli ambienti di sviluppo basati sull’intelligenza artificiale, in particolare negli ambienti collaborativi in cui codice, file di configurazione e plugin basati sull’IA vengono spesso condivisi tra team e repository.
È stato così scoperta una vulnerabilità ad alto impatto nel sistema Model Context Protocol (MCP) di Cursor che consente l’esecuzione persistente di codice remoto (RCE). Una volta che un utente approva una configurazione MCP, un attaccante può modificarne silenziosamente il comportamento. Da quel momento in poi, ogni volta che il progetto viene aperto, è possibile eseguire comandi malevoli senza effettuare ulteriori richieste o notifiche.
L’attaccante può:
- Aggiungere una configurazione MCP dall’aspetto innocuo a un repository condiviso.
- Attendere che la vittima estragga il codice e lo approvi una volta in Cursor IDE.
- Sostituire la configurazione MCP con un payload dannoso.
- Ottenere l’esecuzione silenziosa e persistente del codice ogni volta che la vittima apre Cursor IDE.
Negli ambienti di codifica condivisi, il difetto trasforma un MCP affidabile in un punto di compromissione furtivo e persistente. Per le organizzazioni che si affidano a strumenti di IA come Cursor, le implicazioni sono gravi: accesso silenzioso e continuo ai computer degli sviluppatori, alle credenziali e ai codici base, il tutto innescato da una singola approvazione affidabile.
Come funziona la vulnerabilità
Cursos utilizza un sistema chiamato Model Context Protocol (MCP). Si tratta di file di configurazione che indicano a Cursor come automatizzare determinate attività. Considerateli come un modo per gli sviluppatori di integrare strumenti, script o flussi di lavoro basati sull’intelligenza artificiale direttamente nel loro ambiente di codifica.
Quando un utente apre un progetto che contiene una configurazione MCP, Cursor mostra una richiesta di approvazione una tantum che chiede se fidarsi o meno. Ma ecco il problema: una volta approvato un MCP, Cursor non lo controlla mai più, anche se i comandi al suo interno vengono modificati silenziosamente in un secondo momento.
Ciò significa che l’attaccante che lavora nella stessa repository condivisa potrebbe:
- Aggiungere una configurazione MCP dall’aspetto completamente sicuro a un progetto.
- Aspettare che qualcun altro del team la recuperi.
- Modificare successivamente la configurazione per eseguire azioni dannose come l’avvio di uno script, l’apertura di una backdoor o l’invio di dati a un server esterno.
Ogni volta che la vittima apre il progetto in Cursor, il nuovo comando viene eseguito automaticamente senza una nuova richiesta o avviso.
Da MCP innocuo a exploit persistente
Simulando un tipico scenario di attacco in un progetto condiviso:
Fase 1: un MCP innocuo
L’autore dell’attacco prima esegue il commit di una configurazione MCP completamente sicura. Qualcosa di innocuo come un comando che stampa semplicemente un messaggio. Quando la vittima apre il progetto vede un prompt che chiede di approvare questo MCP.
Fase 2: passaggio silenzioso a un comportamento dannoso
Dopo l’approvazione, l’autore dell’attacco modifica silenziosamente la configurazione MCP con codice malevolo, ad esempio uno script che apre una shell inversa o esegue comandi di sistema dannosi.
Fase 3: l’esecuzione automatica si ripete
Ogni volta che la vittima apre il progetto in Cursor IDE, il comando viene eseguito silenziosamente senza avvisi o richieste di conferma.
Fase 4: accesso persistente e invisibile
Ciò consente all’autore dell’attacco di accedere ripetutamente e in modo invisibile al computer della vittima, rendendo possibile il furto di dati, l’esecuzione di ulteriori attacchi o lo spostamento laterale nell’ambiente della vittima.
Poiché molte organizzazioni condividono e sincronizzano i progetti tramite repository, questa vulnerabilità crea un modo ideale per gli autori degli attacchi di stabilire punti d’appoggio nascosti a lungo termine.
Il pericolo di questa vulnerabilità:
- Persistenza silenziosa: il codice malevolo viene eseguito ogni volta che si apre un progetto, senza avvisare gli utenti o richiedere ulteriori approvazioni. Gli attaccanti possono così mantenere un accesso continuo a tempo indeterminato.
- Ampia superficie di attacco: qualsiasi sviluppatore con accesso in scrittura a un repository condiviso può inserire e modificare le configurazioni MCP affidabili, mettendo a rischio interi team e aziende.
- Rischi di Privilege escalation: i computer degli sviluppatori spesso contengono credenziali sensibili, chiavi di accesso al cloud o altri segreti memorizzati localmente. Un attaccante che sfrutta questa vulnerabilità può utilizzarli per aumentare ulteriormente l’accesso alle reti aziendali.
- Esposizione di dati e codice: oltre all’esecuzione diretta del codice, gli aggressori potrebbero sottrarre codice sorgente, proprietà intellettuale o comunicazioni interne senza essere rilevati.
- Fiducia nella catena di strumenti di IA compromessa: man mano che strumenti di IA come Cursor diventano più integrati nello sviluppo di software, il loro modello di sicurezza deve essere a prova di bomba. Questa vulnerabilità evidenzia i pericoli di una fiducia cieca nei flussi di lavoro automatizzati.
Per le aziende che si affidano a Cursor e IDE simili basati sull’intelligenza artificiale, comprendere e affrontare questa vulnerabilità è fondamentale per proteggere i propri ambienti di sviluppo e le risorse sensibili.
Divulgazione e mitigazione
Dopo aver scoperto questa vulnerabilità, Check Point Research ha segnalato il problema al team di sviluppo di Cursor il 16 luglio 2025. Cursor ha rilasciato una correzione il 30 luglio 2025.
Per mitigare questa classe di vulnerabilità negli ambienti di sviluppo assistiti dall’intelligenza artificiale, Check Point suggerisce di:
- Trattare i file di configurazione MCP come superfici di attacco: proprio come il codice sorgente, gli script di automazione e le definizioni di configurazione MCP devono essere rivisti, controllati e sottoposti a un attento controllo delle versioni.
- Evitare la fiducia implicita nelle automazioni basate sull’intelligenza artificiale: anche se un MCP o un suggerimento sembrano innocui, assicurarsi che i membri del team ne comprendano il funzionamento prima di approvarli.
- Limitare i permessi di scrittura negli ambienti collaborativi: controllare chi può modificare i file di configurazione affidabili, in particolare nei repository condivisi.
Check Point consiglia agli sviluppatori, ai team di sicurezza e alle organizzazioni di rimanere vigili, verificare i propri ambienti di sviluppo IA e a collaborare strettamente con i fornitori per affrontare le minacce emergenti. Solo attraverso una sicurezza proattiva si può sfruttare in modo sicuro la potenza dell’IA nello sviluppo di software.
