Il 29 ottobre 2026, per circa undici ore, nel marketplace delle estensioni di Cursor è circolata una versione manomessa dell’estensione ufficiale di Claude Code. Non un clone con un nome simile: proprio il pacchetto anthropic.claude-code, versione 2.1.313, con qualche riga di codice in più rispetto all’originale.
Quelle righe installavano una backdoor SSH persistente sul computer dello sviluppatore. Cursor ha stimato al massimo 5.000 utenti coinvolti, ha rimosso la versione e ha spento il marketplace per qualche ora. Anthropic ha pubblicato la 2.1.314. La ricostruzione completa dell’accaduto è stata pubblicata da The Hacker News, mentre l’analisi tecnica del campione arriva da OpenSourceMalware.
La parte interessante non è l’ennesimo attacco alla supply chain. È il metodo: nessun installer sospetto, nessun file eseguibile scaricato, nessuna richiesta di permessi. Solo codice aggiunto in testa a un’estensione che gli sviluppatori si aspettano di trovare lì, con lo stesso nome e lo stesso comportamento apparente.
Di cosa parleremo..
Cosa è successo, in ordine
La versione manomessa è stata resa disponibile nel marketplace di Cursor intorno alle 2:27 del mattino del 29 ottobre, ora della costa pacifica. È rimasta scaricabile fino alle 13:35, sempre ora della costa pacifica. Poco meno di undici ore, il tempo sufficiente perché l’aggiornamento automatico la installasse su chi aveva l’estensione configurata in quel modo.
Cursor ha dichiarato di aver rimosso il pacchetto appena rilevato il problema, di aver bloccato la distribuzione e di aver chiuso l’intero marketplace per precauzione, per poi ricostruirlo e rimetterlo online. L’azienda sostiene di aver verificato che nessun’altra estensione è stata alterata.
Il punto più importante, spesso perso nei titoli allarmistici: non è Anthropic ad aver pubblicato quella versione. Il pacchetto npm di Claude Code non era coinvolto e nemmeno le versioni distribuite su Open VSX e sul marketplace di Microsoft. OpenSourceMalware lo scrive in modo esplicito, dopo essere stato contattato da Cursor: l’origine era il marketplace di Cursor, non Open VSX. Le prime ricostruzioni avevano indicato il registro sbagliato e sono state corrette nelle ore successive.
Le 66 righe prima dell’estensione vera
Il file alterato è uno solo: extension.js. Il resto del pacchetto è identico all’originale, compreso il binario incluso. La differenza sta in un blocco di 66 righe inserito all’inizio del bundle, una funzione che parte da sola appena il file viene caricato.
Quel blocco importa i moduli Node.js per processo, filesystem, sistema operativo, HTTP e crittografia. Poi esegue la sua routine e lascia partire l’estensione legittima, che continua a funzionare normalmente. Il pacchetto non dichiara script di installazione, build o postinstall: tutto avviene a runtime, quando VS Code o Cursor caricano l’estensione.
Non serve aprire una conversazione con Claude. Basta che l’editor si avvii e che la webview dell’estensione venga aperta una volta. Da lì in poi il codice malevolo ha già fatto il suo lavoro e quasi ogni errore viene soppresso per non lasciare tracce visibili.
Da sapere: la differenza tra un’estensione sospetta e questa è che qui non c’era nulla da notare. Nome corretto, editore corretto, interfaccia corretta, comportamento corretto. L’unica anomalia era un file JavaScript con qualche riga in più, visibile solo aprendo il pacchetto.
Cosa finiva dentro la macchina
La catena è composta da quattro passaggi, tutti abbastanza semplici da passare inosservati su una macchina di sviluppo.
Una chiave SSH con un nome innocuo
Se la cartella home esiste, il codice crea ~/.ssh con permessi 0700 e aggiunge una chiave Ed25519 al file authorized_keys, portato a 0600. La chiave è commentata svc-telemetry, un’etichetta che sembra appartenere a un account di monitoraggio aziendale.
Il commento non ha alcun effetto tecnico, ma è ciò che rende la chiave poco memorabile a un controllo veloce. La sua impronta è nota e pubblica, quindi confrontabile con quello che c’è sul disco.
Il tunnel inverso verso un server esterno
Il codice include una chiave privata OpenSSH codificata in base64, la decodifica in un file temporaneo e apre una connessione verso [email protected]. Il comando contiene l’opzione -R ‘*:0:localhost:22’: chiede al server remoto di aprire una porta e di girarla verso la porta 22 della macchina vittima.
In pratica, chi controlla quel server può arrivare al servizio SSH del computer senza avere un indirizzo raggiungibile. La connessione disattiva la verifica dell’host, ignora il file known_hosts e si riconnette ogni 60 secondi se cade. Su macOS e Linux usa autossh quando disponibile, altrimenti ssh.
Persistenza su misura per ogni sistema
Su macOS scrive ~/.config/.smt, ~/.config/.smtk e un LaunchAgent chiamato com.apple.sysmond.plist, con RunAtLoad e KeepAlive attivi. Il nome imita un componente Apple, ma non lo è.
Su Linux usa gli stessi file sotto ~/.config e aggiunge una voce @reboot nel crontab dell’utente. Su Windows scrive smt.cmd e smtk, prova a creare un’attività pianificata chiamata SysMon con esecuzione come SYSTEM e, se non ci riesce, copia sysmon.cmd nella cartella Startup.
La ricognizione, prima di tutto il resto
Dopo circa un secondo e mezzo il codice raccoglie un pacchetto di informazioni sulla macchina: nome host, utente locale, sistema operativo, architettura della CPU, cartella home, directory di lavoro corrente e indirizzo email globale di Git. A queste aggiunge i nomi di un massimo di 40 variabili d’ambiente che contengono parole come KEY, TOKEN, SECRET, PASS, AWS o GCP.
Poi chiede il proprio indirizzo IP pubblico a ifconfig.me e api.ipify.org e manda tutto in POST a 134.209.82.225:8099/beacon, in HTTP semplice, senza cifratura. Una copia del tentativo passa anche da 127.0.0.1:8099, sulla macchina locale.
Perché i nomi bastano: il beacon non contiene i valori delle variabili, solo le etichette. Sembra un dettaglio rassicurante, ma non lo è. Sapere che su una macchina esistono AWS_ACCESS_KEY_ID e GITHUB_TOKEN dice all’attaccante quali credenziali cercare una volta entrato via SSH. Ed è esattamente il passo successivo previsto dalla catena.
Il limite che ridimensiona il rischio
Per avviare il servizio SSH locale servono privilegi amministrativi. L’estensione non li ha sulla maggior parte delle macchine macOS e Windows, quindi quel passaggio fallisce. Senza servizio SSH attivo, il tunnel verso la porta 22 non porta da nessuna parte.
È il motivo per cui Cursor scrive che, fuori da circostanze anomale come un editor avviato come amministratore, l’accesso non sarebbe stato possibile. La precisazione è corretta, ma va letta per intero: la chiave viene aggiunta comunque, la persistenza viene installata comunque, i dati sulla macchina vengono inviati comunque. Il fallimento di un passaggio non annulla gli altri.
Cursor aggiunge che il server dell’attaccante non è più operativo, perché è stato spento insieme al provider che lo ospitava. Questo interrompe il canale, non ripulisce le macchine su cui il payload è già stato eseguito.
Come verificare in trenta secondi
Il controllo è una riga di comando, perché la chiave lascia un commento riconoscibile dentro authorized_keys. Su macOS e Linux:
grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "chiave trovata" || echo "nessuna chiave"
Su Windows, in PowerShell:
$files = "$HOME.sshauthorized_keys", "C:ProgramDatasshadministrators_authorized_keys" | Where-Object { Test-Path $_ }; if ($files -and (Select-String svc-telemetry $files)) { "chiave trovata" } else { "nessuna chiave" }
Se il comando risponde che la chiave c’è, la macchina è stata colpita e va trattata come compromessa. Se non c’è, il payload non ha completato quella parte, ma resta sensato controllare anche i file di persistenza e le connessioni SSH in corso, perché un errore soppresso potrebbe aver nascosto un passaggio fallito a metà.
Cosa fare se il controllo trova la chiave
La sequenza indicata da Cursor è quella classica, nell’ordine giusto. Prima si isola la macchina dalla rete, poi si conservano le evidenze, poi si rimuovono chiave, persistenza e processi del tunnel. Solo dopo si ruotano le credenziali, da un sistema pulito: password, token API, sessioni, chiavi cloud e credenziali Git accessibili da quell’account.
Cursor mette a disposizione due script, remediate-macos.sh e remediate-windows.ps1, da scaricare dal sito ufficiale. Il primo va eseguito come utente interessato, non come root. Il secondo da PowerShell aperto come amministratore. Entrambi escono con un codice di errore se qualcosa resta sul sistema.
Disinstallare l’estensione non basta. Questo è il punto su cui vale la pena insistere: il payload scrive script autonomi che continuano a girare anche dopo la rimozione del pacchetto. Su una macchina che ha eseguito il codice, la ricostruzione del sistema è l’opzione più sicura, non l’ultima spiaggia.
La lezione vale anche per chi non usa Cursor
Il caso non riguarda solo Cursor e non riguarda solo Claude Code e non è nemmeno il primo: a luglio ho raccontato il caso di Grok Build e del codice finito su Google Cloud. Riguarda il modo in cui trattiamo i marketplace di estensioni: come infrastruttura fidata, aggiornata in automatico, montata su macchine che contengono chiavi di produzione.
Un’estensione è codice che gira con i permessi dell’editor. Se l’editor ha accesso al filesystem, alla rete e ai terminali, l’estensione ha gli stessi accessi. In un flusso di lavoro con agenti che leggono repository e lanciano comandi, la superficie non è più il singolo file aperto, ma tutto ciò che quell’ambiente può toccare.
Qualche abitudine concreta: fissare le versioni delle estensioni usate sui progetti importanti, disattivare l’aggiornamento automatico dove non serve, controllare l’editore e non solo il nome del pacchetto, tenere le chiavi cloud fuori dalle macchine di sviluppo quando è possibile. Nessuna di queste contromisure avrebbe fermato un attacco arrivato dal marketplace ufficiale con il pacchetto giusto, ma tutte riducono la finestra in cui un errore di quel tipo diventa un incidente.
Domande frequenti
La mia estensione Claude Code su VS Code è a rischio?
No, se l’hai installata dal marketplace di Microsoft o da Open VSX. La versione manomessa è passata dal marketplace di Cursor e riguarda il pacchetto 2.1.313 distribuito lì. Anthropic ha pubblicato la 2.1.314; aggiornare resta la cosa sensata da fare, ma non c’è motivo di considerare compromessa una macchina che non ha mai visto quel pacchetto.
Ho installato la 2.1.313 da Cursor: come controllo?
Apri il terminale e cerca il commento svc-telemetry dentro ~/.ssh/authorized_keys, come nella riga di comando più sopra. Se la chiave c’è, la macchina è stata colpita. Se non c’è, controlla comunque i file di persistenza elencati da Cursor, perché la chiave potrebbe essere stata rimossa da un controllo precedente senza che il resto sia stato ripulito.
Gli script di rimozione di Cursor sono affidabili?
Sono pubblicati sul sito ufficiale dell’azienda e fanno esattamente ciò che descrivono: rimuovono estensione, persistenza, processi del tunnel e chiave aggiunta. Vanno eseguiti con i privilegi indicati e se la macchina conteneva credenziali di produzione la rotazione delle stesse resta obbligatoria a prescindere dallo script.
Il server dell’attaccante è spento, quindi sono al sicuro?
Il server non risponde più, quindi il tunnel non porta da nessuna parte. Ma la chiave SSH e i meccanismi di persistenza restano sulla macchina e potrebbero essere riattivati se il codice viene eseguito di nuovo o se l’attaccante torna con un’altra infrastruttura. La pulizia va fatta comunque.
Devo cambiare tutte le password?
Non tutte, ma tutte quelle raggiungibili da quella macchina: credenziali cloud, token API, chiavi SSH, sessioni Git e accessi ai repository. La regola pratica è partire da ciò che l’account poteva leggere senza chiedere permessi aggiuntivi, poi allargare il perimetro se la macchina aveva accesso a sistemi condivisi.
Fonti: The Hacker News, Cursor Security Notice e analisi OpenSourceMalware del 30 ottobre 2026.
