Claude Code su Cursor: 2 versioni infette, cosa fare

Se hai installato o aggiornato l’estensione anthropic.claude-code dal marketplace di Cursor il 29 ottobre 2026, controlla subito la versione e la provenienza. Le release 2.1.312 e 2.1.313 distribuite per alcune ore da quel marketplace contenevano codice malevolo capace di tentare l’installazione di una backdoor SSH. La presenza di una versione interessata richiede verifiche; non significa, da sola, che qualcuno abbia ottenuto accesso al PC.

Verifica prima la versione e il canale di installazione. Se rientri nella finestra dell’incidente, passa ai controlli di sola lettura descritti nella guida e conserva eventuali risultati sospetti prima di intervenire.

Verifica pratica consigliata al lettore: apri Cursor, vai nella sezione Estensioni e cerca anthropic.claude-code. Annota la versione installata e il marketplace di provenienza. Non installare né eseguire pacchetti sospetti per effettuare il controllo.

ScelgoIo non ha eseguito questo controllo su un dispositivo personale e non pubblica screenshot presentati come prova diretta. L’articolo è un’analisi di sicurezza documentale basata sulle comunicazioni ufficiali di Cursor e Microsoft.

1. Chi deve preoccuparsi della falsa estensione Claude Code?

Il perimetro descritto nell’avviso ufficiale è preciso: estensione anthropic.claude-code, versioni 2.1.312 o 2.1.313, ottenute tramite il Cursor VS Code Extension Marketplace nell’intervallo in cui sono state pubblicate le copie alterate. Cursor colloca la disponibilità fra le 2:27 e le 13:35, ora del Pacifico, del 29 ottobre. Non è sufficiente aver usato Cursor quel giorno: conta il pacchetto effettivamente installato, anche attraverso un eventuale aggiornamento automatico.

L’avviso di Cursor riguarda distribuzioni per Windows e macOS. Microsoft descrive nel codice anche comportamenti per ambienti Unix-like: la presenza di questi rami non prova, da sola, una distribuzione malevola su Linux.

Tre situazioni richiedono risposte diverse: estensione mai installata, pacchetto proveniente da un canale non coinvolto oppure versione interessata scaricata dal marketplace Cursor. La cronologia di installazione è decisiva per stabilire quali controlli approfondire.

La finestra temporale è rilevante perché Cursor ha dichiarato di aver rimosso i pacchetti, sospeso temporaneamente il marketplace, ricostruito l’infrastruttura e fatto disattivare il server usato dagli aggressori. Sono misure importanti, ma un server spento non cancella automaticamente eventuali modifiche già effettuate su un dispositivo.

2. Che cosa è accaduto il 29 ottobre e quali versioni erano coinvolte?

Cursor ha segnalato l’incidente il 29 ottobre 2026; Microsoft ha pubblicato un’analisi del JavaScript inserito nel pacchetto il giorno successivo. Le copie malevole erano presentate come l’estensione Claude Code, ma non erano state sviluppate da Anthropic. Il codice aggiunto veniva eseguito prima della normale inizializzazione dell’estensione, sfruttando i privilegi già concessi al processo dell’editor.

Verifica	Informazione documentata	Conseguenza pratica
Identificativo	anthropic.claude-code	Controllare l’ID, non soltanto l’icona o il nome
Versioni segnalate	2.1.312 e 2.1.313	Cercarle anche nella cronologia degli aggiornamenti
Canale coinvolto	Marketplace delle estensioni di Cursor	La provenienza è determinante
Data	29 ottobre 2026	Ricostruire installazioni e update di quella giornata
Piattaforme esplicitate da Cursor	Windows e macOS	Non generalizzare automaticamente a ogni sistema
Effetto possibile	Tentativo di backdoor SSH persistente	Verificare anche ciò che resta fuori dall’estensione

Microsoft precisa che i pacchetti malevoli non sono stati pubblicati sul Microsoft Visual Studio Marketplace e che il pacchetto npm ufficiale @anthropic-ai/claude-code non risulta coinvolto. Anthropic ha confermato a Microsoft che i propri sistemi non erano stati compromessi. Non c’è quindi motivo di titolare che l’azienda Anthropic o l’intero ecosistema Claude Code siano stati violati.

L’episodio è un esempio di attacco alla catena di distribuzione del software: l’utente pensa di aggiornare uno strumento noto e invece esegue codice aggiunto in un passaggio della distribuzione. Il fatto che l’estensione continui ad aprirsi e svolgere le proprie funzioni non dimostra che sia pulita. Qui il rischio deriva proprio dalla fiducia concessa a un aggiornamento apparentemente ordinario.

3. Come funzionava la backdoor SSH nascosta nell’estensione?

L’analisi Microsoft ricostruisce cinque tentativi successivi: raccolta di informazioni sul computer, aggiunta di una chiave SSH autorizzata, preparazione di un tunnel inverso, creazione di meccanismi di persistenza e invio di dati di ricognizione. Sono capacità e azioni tentate dal codice, non la prova che ogni passaggio sia riuscito su tutti i dispositivi.

Nella fase di ricognizione il codice leggeva informazioni su dispositivo, utente e configurazione Git. Individuava inoltre i nomi di variabili d’ambiente contenenti parole come KEY, TOKEN e SECRET: la telemetria iniziale analizzata da Microsoft non dimostra che ne abbia trasmesso anche i valori.

Il passaggio successivo tentava di aggiungere una chiave pubblica controllata dall’aggressore al file authorized_keys. Quel file indica quali identità SSH possono autenticarsi sul computer, quando esiste un servizio SSH accessibile e correttamente configurato. Il commento associato alla chiave era svc-telemetry: un nome che sembra tecnico e innocuo, ma che nel contesto dell’indicatore pubblicato merita attenzione.

Per il collegamento remoto il codice tentava di aprire un tunnel SSH inverso. In termini semplici, anziché aspettare una connessione dall’esterno verso il PC, sarebbe stato il PC a iniziare una connessione verso un server controllato dall’attaccante, chiedendo di inoltrare traffico verso il servizio SSH locale. Questo meccanismo può aggirare alcune difficoltà tipiche delle connessioni in ingresso, ma non garantisce automaticamente l’accesso: servono permessi, servizio SSH attivo e configurazione favorevole alle due estremità.

Cursor segnala che errori di implementazione e richieste di privilegi amministrativi hanno limitato l’attivazione del servizio SSH su molti sistemi Windows e macOS. Rimane comunque rilevante verificare eventuali file di persistenza lasciati sul dispositivo.

Per capire come una backdoor possa mantenere un accesso remoto senza somigliare a un malware tradizionale, può essere utile leggere anche l’approfondimento ScelgoIo sulle backdoor individuate nei router ZBT: il contesto è diverso, ma il tema comune è la persistenza di un accesso non autorizzato.

4. Come controllare la versione installata in Cursor?

Apri Cursor sul computer potenzialmente interessato. Prima di cancellare o aggiornare qualcosa, raccogli le informazioni essenziali, perché dopo una sostituzione automatica la versione attualmente visibile potrebbe non raccontare tutta la storia.

1. Apri la vista Estensioni dalla barra laterale o con la scorciatoia del tuo sistema.
2. Cerca Claude Code tra le estensioni installate, non soltanto tra i risultati del marketplace.
3. Apri la scheda dell’estensione e controlla identificativo, versione e origine disponibili nell’interfaccia.
4. Annota eventuali versioni 2.1.312 o 2.1.313 e la data in cui Cursor è stato utilizzato o aggiornato il 29 ottobre.
5. Se il computer appartiene a un’azienda, avvisa chi gestisce la sicurezza prima di disinstallare: log e cartelle potrebbero servire a ricostruire gli eventi.

Non tutte le installazioni mostrano nello stesso modo il canale di provenienza o la cronologia. In un contesto amministrato occorre quindi incrociare i registri di installazione, le cartelle dell’estensione e gli strumenti di inventario software. L’assenza della versione incriminata nell’elenco oggi non esclude che sia stata installata e poi sostituita nei giorni precedenti.

Un aggiornamento non affidabile può comportare conseguenze anche su un computer già aggiornato: è un rischio diverso dalle normali vulnerabilità del sistema. Il caso permette di collegare il problema alla guida ScelgoIo su ShieldBreak e Microsoft Defender, che riguarda un’altra tecnica d’attacco e non va confusa con questo incidente.

5. Quali controlli fare su Windows senza modificare il sistema?

Se la cronologia indica un possibile pacchetto coinvolto, il controllo iniziale deve essere di sola lettura. Apri PowerShell e verifica la presenza dei file delle chiavi autorizzate nei percorsi indicati da Microsoft. Non pubblicare online il contenuto completo di questi file: potrebbero includere informazioni su accessi legittimi.

$files = @("$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys")
$files | ForEach-Object {
  if (Test-Path $_) {
    Write-Output "Controllo: $_"
    Select-String -Path $_ -Pattern 'svc-telemetry' -SimpleMatch
  }
}

Se la ricerca mostra una riga, salva il risultato e confrontalo con gli indicatori ufficiali prima di modificare il file. Se non compare nulla, il comando non ha trovato la stringa nei file controllati oppure quei file non esistono: non è una prova che il computer sia sicuro.

Controlla poi, tramite Esplora file o strumenti amministrativi, se esistono elementi coerenti con i percorsi indicati da Microsoft: %USERPROFILE%\.config\smt.cmd, %USERPROFILE%\.config\smtk e lo script sysmon.cmd nella cartella di esecuzione automatica dell’utente. Non aprire uno script sconosciuto per eseguirlo: puoi consultarlo in modo sicuro come testo con un editor affidabile, preferibilmente dopo averne preservato una copia.

Nel pannello Utilità di pianificazione verifica eventuali attività chiamate SysMon, concentrandoti non sul nome ma sull’azione configurata e sul programma che verrebbe lanciato. SysMon è una denominazione che può richiamare software legittimo di monitoraggio: un nome isolato non consente di dichiarare infetto il PC. Servono correlazione con percorsi, comandi, tempi di creazione e installazione dell’estensione.

Per chi gestisce numerosi dispositivi, Microsoft pubblica anche query di hunting per Defender XDR. Sono strumenti professionali che incrociano processi, file e rete: non vanno sostituiti con la semplice ricerca di una parola in Esplora file. Se emergono risultati coerenti con i pacchetti malevoli, la priorità passa dalla verifica alla risposta all’incidente.

6. Come verificare macOS e cosa sapere per Linux?

Su macOS, Microsoft segnala l’eventuale aggiunta della chiave nel file ~/.ssh/authorized_keys, uno script in ~/.config/.smt, una chiave di tunnel in ~/.config/.smtk e l’elemento di avvio ~/Library/LaunchAgents/com.apple.sysmond.plist. Puoi effettuare un controllo iniziale aprendo Terminale e usando comandi che cercano i nomi senza eseguire i file sospetti.

grep -n 'svc-telemetry' "$HOME/.ssh/authorized_keys" 2>/dev/null
ls -ld "$HOME/.config/.smt" "$HOME/.config/.smtk" "$HOME/Library/LaunchAgents/com.apple.sysmond.plist" 2>/dev/null

Il primo comando cerca la stringa in una chiave autorizzata; il secondo elenca l’eventuale presenza dei file. Nessuno dei due esegue il contenuto. Se il Mac è utilizzato per sviluppo professionale, non rimuovere un LaunchAgent soltanto perché il nome sembra sospetto: osserva a quale script punta e confrontalo con l’avviso del produttore. Anche un file presente può essere stato creato per una ragione diversa.

Su Linux l’analisi Microsoft descrive uno script ~/.config/.smt, una chiave ~/.config/.smtk e un possibile comando @reboot nel crontab dell’utente. Questo è un riferimento tecnico alla logica del malware: l’avviso di distribuzione Cursor identifica Windows e macOS. Se stai investigando un ambiente Linux che ha ricevuto pacchetti da canali non verificati, puoi controllare in lettura authorized_keys, gli stessi percorsi nella cartella personale e le voci del crontab.

grep -n 'svc-telemetry' "$HOME/.ssh/authorized_keys" 2>/dev/null
ls -ld "$HOME/.config/.smt" "$HOME/.config/.smtk" 2>/dev/null
crontab -l 2>/dev/null

Su Linux vale la stessa regola di indagine: esamina insieme cronologia dell’estensione, file, processi, attività pianificate e collegamenti di rete, senza attribuire significato decisivo a un solo nome.

7. Quali indicatori contano davvero e quali possono ingannare?

I due avvisi ufficiali pubblicano indicatori di compromissione: hash dei pacchetti alterati, un hash del codice JavaScript, indirizzi di rete, impronta di chiave SSH, nomi dei file di persistenza e particolari opzioni usate da SSH. Sono strumenti per cercare tracce, non una lista di parole che provano automaticamente un attacco.

Traccia	Che cosa suggerisce	Perché non basta da sola
Versione 2.1.312 o 2.1.313	Possibile esposizione se proveniente dal marketplace Cursor	Va verificata la provenienza e il periodo
svc-telemetry in authorized_keys	Possibile aggiunta della chiave non autorizzata	Va confrontata l’impronta completa
File .smt o smt.cmd	Possibile script di persistenza	Nome e contesto possono essere ambigui
Attività SysMon	Possibile avvio automatico malevolo	Nome utilizzabile anche in contesti legittimi
Connessione verso l’indirizzo pubblicato da Cursor	Possibile contatto con infrastruttura dell’attacco	Serve capire quale processo ha comunicato e quando
Hash del JavaScript malevolo	Identificazione di uno specifico campione	Non coincide con l’hash di qualsiasi pacchetto VSIX

Un hash è un’impronta digitale calcolata dai byte di un file: serve a confrontare un campione preciso con quello pubblicato in un avviso di sicurezza. In questo caso bisogna distinguere gli hash delle estensioni VSIX per le piattaforme dall’hash del file JavaScript analizzato da Microsoft. Confrontare un file con l’hash di un altro formato produce un risultato negativo anche quando il campione è pertinente. Cursor pubblica impronte differenti per macOS e Windows e per ciascuna delle due versioni.

Non aprire gli indirizzi degli indicatori nel browser per provarli: la raggiungibilità attuale dei server non chiarisce se il codice sia stato eseguito il giorno dell’incidente.

Microsoft ha collegato il comportamento osservato a tecniche MITRE ATT&CK, fra cui l’aggiunta di chiavi SSH autorizzate, il tunneling di protocolli e gli avvii programmati. È una classificazione utile per gli amministratori, ma non identifica da sola l’autore dell’attacco. L’attribuzione a uno specifico gruppo richiederebbe prove ulteriori.

8. Perché disinstallare l’estensione potrebbe non essere sufficiente?

Il codice alterato non rimaneva necessariamente confinato nella cartella dell’estensione. Cercava di scrivere file nelle directory personali, aggiungere una chiave autorizzata e predisporre meccanismi che rilanciassero il tunnel dopo un riavvio o un accesso dell’utente. Disinstallare il pacchetto elimina il punto di ingresso più evidente, ma non garantisce la rimozione di ciò che è stato già creato altrove.

È la differenza tra interrompere una distribuzione malevola e bonificare un computer che l’ha eseguita. Cursor ha rimosso le versioni alterate dal marketplace e lavorato con il provider per spegnere il server; sul singolo dispositivo, però, la verifica deve riguardare anche chiavi, script e configurazioni di avvio. Microsoft raccomanda di preservare le evidenze prima della pulizia, soprattutto in ambito aziendale.

In una postazione aziendale con accesso a repository, cloud o credenziali di produzione, coinvolgi il responsabile IT: conservazione dei log e analisi dell’eventuale accesso vengono prima di una bonifica improvvisata.

Cursor pubblica strumenti ufficiali per Windows e macOS: esamina istruzioni e permessi richiesti e, su dispositivi gestiti, concordane l’uso con il team di sicurezza.

9. Cosa fare se trovi una traccia concreta della backdoor?

L’obiettivo non è cancellare tutto il più velocemente possibile. Bisogna conservare gli elementi che permettono di capire se c’è stato un accesso e ridurre contemporaneamente il rischio di ulteriori attività. Per questo la procedura va adattata al contesto, soprattutto su dispositivi utilizzati per lavoro.

1. Registra ciò che hai trovato: versione dell’estensione, data, percorsi e schermate pertinenti. Non pubblicare chiavi o token nei forum.
2. Scollega o isola il dispositivo secondo le procedure appropriate se ci sono prove di esecuzione della backdoor, privilegi anomali o connessioni sospette. Su una rete aziendale coinvolgi subito l’amministratore.
3. Preserva i file utili all’analisi prima di una rimozione: script, chiavi non autorizzate, informazioni sull’attività pianificata e log disponibili.
4. Rimuovi solo gli elementi confermati, confrontando gli indicatori con le fonti Cursor e Microsoft. Non cancellare chiavi SSH legittime né attività dal nome generico.
5. Verifica processi, accessi e rete per capire se la persistenza è stata attivata e se vi sono state sessioni SSH o operazioni non autorizzate.
6. Cambia le credenziali da un dispositivo pulito e revoca le sessioni quando l’indagine evidenzia possibile accesso ai segreti o non è possibile ristabilire la fiducia nel computer.
7. Valuta una reinstallazione completa nei casi più gravi, poi verifica che le tracce non ricompaiano dopo accesso e riavvio.

Le credenziali da valutare non sono solo la password dell’account principale. Chi sviluppa può conservare token Git, chiavi per servizi cloud, credenziali di database e accessi a repository privati. Il fatto che il loader iniziale abbia raccolto soprattutto nomi di variabili non esclude che un eventuale accesso successivo abbia permesso attività più ampie. Nello stesso tempo, non va presentato come furto confermato ciò che i log non mostrano.

Questo tema si collega alla gestione delle autorizzazioni e dei segreti condivisi. Nella guida ScelgoIo su Google Drive e l’opzione «Chiunque abbia il link» il rischio è diverso, ma il principio è lo stesso: un documento o un collegamento condiviso non deve diventare un deposito incontrollato di credenziali, chiavi e informazioni riservate.

10. Che cosa non è stato compromesso e come prevenire incidenti simili?

Le comunicazioni disponibili non descrivono un attacco al Visual Studio Marketplace di Microsoft, né una compromissione dei sistemi Anthropic o del pacchetto npm ufficiale Claude Code. Questo distingue l’incidente da una vulnerabilità universale dell’assistente IA o da un problema che affliggerebbe automaticamente chi usa Claude Code in qualsiasi ambiente.

Per uno sviluppatore il controllo della provenienza delle estensioni dovrebbe essere una pratica ordinaria. Il nome di un publisher è utile, ma non è sufficiente se un canale di distribuzione viene alterato. In team e aziende ha senso approvare le estensioni necessarie, documentare i marketplace consentiti e valutare un ritardo di installazione per gli aggiornamenti appena distribuiti: Cursor richiama proprio queste misure nella propria guida di rafforzamento della sicurezza.

Una misura preventiva utile è non eseguire abitualmente l’editor come amministratore. Per le estensioni di sviluppo conviene inoltre limitare l’accesso ai segreti e usare credenziali con permessi strettamente necessari.

Disattivare indiscriminatamente gli aggiornamenti automatici non è la risposta: in contesti professionali è preferibile un processo controllato di approvazione dei marketplace, monitoraggio delle versioni e distribuzione delle patch.

11. FAQ: le domande pratiche prima di tornare a usare Cursor

Se ho installato Claude Code da VS Code devo preoccuparmi?

Microsoft riferisce che le copie malevole dell’incidente non sono state distribuite tramite il Microsoft Visual Studio Marketplace. Controlla comunque l’origine del pacchetto e non confondere i due marketplace.

Se oggi vedo una versione nuova posso escludere il rischio?

No. Un aggiornamento successivo può aver sostituito quella precedente. Contano anche la cronologia del 29 ottobre e l’eventuale presenza di tracce esterne alla cartella dell’estensione.

Se non trovo svc-telemetry il computer è pulito?

Non è una conclusione sufficiente. L’indicatore va incrociato con estensione installata, script, processi, avvii automatici e traffico di rete. Un singolo controllo negativo non sostituisce l’indagine.

È stato dimostrato che il malware ha rubato i miei token?

Non dalla sola ricognizione descritta da Microsoft: il callback esaminato trasmetteva nomi di variabili d’ambiente, non i relativi valori. Se è avvenuto un accesso successivo al computer, il rischio va valutato separatamente.

Devo eseguire subito lo script di bonifica?

Se risulti potenzialmente coinvolto, leggi prima l’avviso Cursor e le istruzioni per il sistema operativo. Su dispositivi professionali, conserva le evidenze e coinvolgi chi gestisce la sicurezza prima di interventi che possono alterare le tracce.

Il giudizio ScelgoIo: verificare la provenienza prima di intervenire

La risposta di Cursor — rimozione dei pacchetti, sospensione del marketplace e intervento sull’infrastruttura abusata — è stata significativa. Resta però una criticità sostanziale: un canale di distribuzione considerato affidabile ha veicolato codice aggiuntivo a utenti che cercavano un’estensione legittima.

Il giudizio di ScelgoIo è che la rapidità della risposta non cancelli il problema della fiducia nella catena di distribuzione. Per chi sviluppa, un aggiornamento automatico deve essere tracciabile e verificabile; per i gestori dei marketplace, servono controlli che riducano la possibilità di sostituzioni malevole. Il problema non è Claude Code, ma la catena che lo distribuisce. Un nome di pacchetto familiare, da solo, non basta a garantire l’integrità di un aggiornamento.

Fonti primarie e documentazione

• Microsoft Security Research — Inside a malicious Claude Code-branded extension and its persistent SSH backdoor, 30 ottobre 2026. Analisi del codice, persistenza, rete e criteri di indagine.
• Cursor — Security notice, 29 ottobre 2026, aggiornato il 30 ottobre. Versioni coinvolte, finestra di distribuzione, indicatori e strumenti ufficiali di verifica e bonifica.

Ultima verifica delle fonti: 1° novembre 2026.