Estensione Claude Code compromessa su Cursor: la backdoor SSH della versione 2.1.313

Il 29 ottobre 2026 una versione manipolata dell’estensione ufficiale di Claude Code, la 2.1.313, è rimasta disponibile per circa undici ore nel marketplace di estensioni di Cursor. Dentro conteneva una backdoor SSH pensata per aprire una porta sulle macchine degli sviluppatori. Secondo Cursor gli utenti esposti sono al massimo 5.000, mentre Anthropic ha pubblicato il 30 ottobre una versione pulita, la 2.1.314.

Non è un attacco a Claude in sé, ma alla catena con cui gli strumenti di sviluppo arrivano sul tuo computer. Ed è proprio questo il motivo per cui devi leggerlo con attenzione se usi assistenti AI per programmare.

Cosa è successo con l’estensione Claude Code su Cursor

Secondo l’avviso di sicurezza pubblicato da Cursor, la versione compromessa dell’estensione Anthropic.claude-code è stata online tra le 2:27 e le 13:35 del mattino, ora della costa del Pacifico, del 29 ottobre. Cursor ha rimosso il pacchetto non appena ha rilevato il problema, ha bloccato la distribuzione e, in via precauzionale, ha spento l’intero marketplace delle estensioni VS Code. Poi ha ruotato le proprie chiavi, ricostruito il servizio e lo ha rimesso in linea.

Un punto è chiaro: il pacchetto non è stato sviluppato da Anthropic. Come sia stato pubblicato sotto il nome dell’azienda resta, al momento, una questione aperta, e al momento non risulta una dichiarazione ufficiale di Anthropic sulle cause.

Una sola versione, un solo canale

La versione coinvolta è soltanto la 2.1.313. All’inizio alcuni resoconti parlavano anche di npm, Open VSX e del marketplace di Visual Studio Code, ma Cursor ha poi confermato che l’unico canale di distribuzione interessato era il suo. Per ora non ci sono prove che altre versioni dell’estensione o la distribuzione ufficiale siano state toccate, né che altre estensioni siano state manomesse.

Il numero di 5.000 utenti è un tetto massimo, non una stima di compromissioni riuscite. Cursor ha dichiarato che contatterà direttamente le persone interessate.

Come funzionava la backdoor SSH

I ricercatori di Phorion e OpenSourceMalware, citati da BleepingComputer, hanno trovato un loader JavaScript malevolo inserito all’inizio del file extension.js. Il resto del codice era quello legittimo, quindi l’estensione continuava a comportarsi in modo normale. Il codice partiva da solo al caricamento dell’estensione, senza alcuna azione richiesta all’utente.

La parte più delicata è che bastava installare l’aggiornamento perché il malware entrasse in funzione.

Raccolta di informazioni e persistenza

Per prima cosa il malware raccoglieva dati sull’ambiente: nome host, nome utente, sistema operativo, architettura, cartella home, nomi delle variabili d’ambiente, directory di lavoro, indirizzo email di Git e indirizzo IP pubblico. Non sottraeva direttamente le credenziali, ma i nomi delle variabili d’ambiente legate ad accessi sensibili indicano dove gli attaccanti avrebbero potuto cercare in un secondo momento.

Poi tentava di aggiungere al file authorized_keys una chiave SSH dell’attaccante, etichettata svc-telemetry, di abilitare il servizio SSH locale e di aprire un tunnel SSH inverso. Per restare sulla macchina, su macOS usava un LaunchAgent chiamato com.apple.sysmond, mentre su Windows creava un’attività pianificata chiamata SysMon, con un ripiego sulla cartella di avvio. Gli script in background riprovavano il tunnel circa ogni 60 secondi. Infine inviava i dettagli dell’host e lo stato della backdoor, con una richiesta POST sulla porta 8099, a un server controllato dagli attaccanti.

Gli errori che hanno limitato i danni

Secondo Phorion, alcuni errori di programmazione hanno probabilmente impedito l’accesso remoto su molti computer. Su macOS il malware lanciava il comando systemsetup senza privilegi elevati, riceveva un errore e saltava l’attivazione di SSH. Su Windows invocava PowerShell attraverso /bin/sh, che non esiste in una installazione standard, e la configurazione del server OpenSSH falliva.

Attenzione però: anche quando il tunnel non si apriva, la raccolta dei dati e l’invio al server avvenivano comunque. Cursor ricorda inoltre che l’aggiunta della chiave e la persistenza potevano riuscire anche senza diritti di amministratore.

Cosa devi controllare se usi Cursor

Se hai installato o aggiornato l’estensione di Claude Code su Cursor il 29 ottobre, il primo passo è verificare quale versione hai ricevuto. Poi cerca nel file authorized_keys una chiave con il commento svc-telemetry: Cursor ha pubblicato i comandi per farlo, con grep su macOS e Select-String su PowerShell.

Se trovi qualcosa, tratta la macchina come compromessa.

Le indicazioni dell’avviso sono queste: isolare gli host che mostrano l’esecuzione del payload, cercare gli indicatori di compromissione nella telemetria di endpoint e rete, eseguire lo script di rimedio per la tua piattaforma (remediate-macos.sh come utente interessato, non come root, oppure remediate-windows.ps1 come amministratore) e ruotare credenziali e sessioni raggiungibili dal computer, usando un sistema affidabile. Cursor avverte che disinstallare l’estensione potrebbe non bastare e che può essere necessario valutare la ricostruzione dell’host.

Tra gli indicatori ci sono l’indirizzo IP 134.209.82[.]225 e gli hash SHA-256 dei pacchetti modificati, riportati integralmente nell’avviso originale.

Perché questo caso riguarda tutti gli sviluppatori che usano l’AI

Gli assistenti di programmazione come Claude Code hanno accesso a repository, terminale, chiavi e variabili d’ambiente. Chi compromette l’estensione che li ospita non ha bisogno di attaccare il modello: eredita la fiducia che l’utente ha già concesso allo strumento. È lo stesso schema che abbiamo visto in altri episodi recenti, come l’infostealer Aokigahara che ruba le sessioni degli assistenti AI o l’attacco che sfrutta un file AGENTS.md nella cartella dei download.

Il punto in comune è che la superficie d’attacco si sposta dagli errori del modello alla supply chain del software che lo circonda.

Il peso dei marketplace di estensioni

Cursor è un fork di VS Code e gestisce un proprio marketplace, quindi non può contare automaticamente sui controlli di quello di Microsoft. Questo episodio mostra quanto sia delicato controllare chi pubblica sotto il nome di un editore noto. Se in un negozio di estensioni basta presentarsi con il nome giusto, la verifica dell’identità dell’editore diventa il vero perimetro di sicurezza. Anche il fatto che i ricercatori abbiano individuato il codice malevolo analizzando il pacchetto, e non grazie a un blocco automatico, è un segnale da non sottovalutare.

Lo stesso discorso vale per gli strumenti di lavoro che usi tutti i giorni nel tuo flusso di sviluppo, come gli agenti che già oggi controllano le app del desktop su Cursor: più un agente ha permessi ampi, più un aggiornamento compromesso diventa costoso.

Cinque abitudini per ridurre il rischio

Nessuna misura da sola ti protegge, ma alcune abitudini riducono molto l’esposizione. Prima di tutto, disattiva gli aggiornamenti automatici delle estensioni sui computer che contengono chiavi di produzione e aggiorna dopo qualche ora, quando la comunità ha già avuto modo di segnalare eventuali anomalie. In questo caso la finestra di rischio era di sole undici ore, e un ritardo minimo avrebbe fatto la differenza.

In secondo luogo, controlla periodicamente il file authorized_keys e le voci di avvio automatico del sistema, e verifica il numero di versione delle estensioni critiche rispetto a quello annunciato dal produttore. Terzo, separa le credenziali: usa token con permessi minimi e scadenza breve, e non tenere segreti a lungo termine nelle variabili d’ambiente della sessione di sviluppo. Quarto, lavora su ambienti isolati, come container o macchine virtuali, per i progetti più sensibili. Quinto, tieni un inventario aggiornato delle estensioni installate nel tuo team e rimuovi quelle che non servono.

Sono accorgimenti semplici, ma cambiano il bilancio tra un incidente da archiviare e uno da gestire per settimane.

Cosa resta da chiarire

Mancano ancora risposte importanti. Non è noto come gli attaccanti siano riusciti a pubblicare un pacchetto con il nome di Anthropic, né se siano stati compromessi sistemi di Cursor, di Anthropic o altri. Cursor sostiene di non avere trovato prove di manomissioni ad altre estensioni, ma il fatto che abbia dovuto spegnere e ricostruire l’intero marketplace dà la misura della gravità del rischio che ha percepito.

L’esito più utile sarà un’indagine tecnica completa, con una spiegazione chiara del meccanismo di pubblicazione abusiva e dei controlli aggiunti per evitare che si ripeta.

Conclusioni: aggiorna, verifica e ruota i segreti

La lezione pratica è semplice: se usi Cursor con Claude Code, installa la versione pulita 2.1.314, controlla la presenza della chiave svc-telemetry e, se hai il minimo dubbio, ruota le credenziali. Tratta ogni estensione come codice che gira con i tuoi permessi, perché è esattamente quello che è.

Se segui l’evoluzione della sicurezza degli strumenti AI per sviluppatori, continua a leggere le nostre news: ne parleremo man mano che arriveranno gli aggiornamenti di Cursor e Anthropic, e ti consigliamo di condividere questo articolo con il tuo team, per fare insieme un controllo rapido delle estensioni installate.