Estensione Claude Code manomessa su Cursor: per circa 11 ore ha tentato di installare backdoor SSH, nessun furto di crypto segnalato

Una copia manomessa dell’estensione Claude Code, pubblicata a nome di Anthropic sul marketplace di Cursor, ha tentato per circa 11 ore, blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il 29 ottobre 2026, di installare una backdoor SSH sui computer degli sviluppatori, come ha comunicato Cursor in un avviso di sicurezza. Non risulta alcun furto di crypto, e nessuna fonte dice che un wallet sia stato toccato o che il valore di un segreto sia uscito da una macchina.

Le versioni coinvolte sono Anthropic.claude-code 2.1.312 e 2.1.313 per Windows e macOS, distribuite dal Cursor VS Code Extension Marketplace tra le 2:27 e le 13:35 circa, ora del Pacifico. Sono le 09:27-20:35 UTC: quel giovedì negli Stati Uniti vigeva ancora l’ora legale (UTC-7), e The Register indica gli stessi orari UTC. Secondo Cursor, queste versioni «non sono state sviluppate da Anthropic».

Chi lavora sulle crypto ha motivo di guardare con più attenzione se ha eseguito quelle versioni. CryptoSlate osserva che i consigli di Cursor varrebbero anche per le credenziali di sviluppo o di servizi finanziari legate all’account interessato, se presenti. Sulla base delle prove pubblicate, il codice puntava all’accesso remoto più che ai fondi, e la pulizia va oltre l’estensione: Cursor avverte che «disinstallare l’estensione potrebbe non bastare».

Come funzionava la backdoor dell’estensione Claude Code su Cursor

Il fornitore di sicurezza per gli endpoint Phorion, che secondo The Register ha individuato per primo la backdoor, ha pubblicato un’analisi dettagliata, e l’avviso di Cursor coincide con essa sulle fasi principali. BleepingComputer attribuisce il merito anche a ricercatori di OpenSourceMalware. Codice aggiuntivo era inserito all’inizio del file extension.js minificato e partiva non appena Node caricava quel file, prima dell’attivazione dell’estensione: nessuno doveva cliccare nulla. Secondo Cursor e Phorion, procedeva poi in queste fasi:

1. Aggiungeva al file authorized_keys dell’utente una chiave Ed25519 controllata dall’attaccante, con il commento svc-telemetry.
2. Tentava di attivare il servizio SSH locale. Non usava alcun exploit, quindi servono i diritti di amministratore o sudo senza password. Cursor afferma che l’estensione non li ha sulla maggior parte dei computer macOS e Windows, dove questo passaggio fallisce.
3. Tentava di aprire un tunnel SSH inverso verso il server 134.209.82.225, riprovando circa ogni 60 secondi e staccato dall’editor, così che chiudere Cursor non lo fermasse.
4. Installava la persistenza: un LaunchAgent su macOS, un’attività pianificata chiamata SysMon su Windows con ripiego nella cartella Esecuzione automatica (Startup), e una voce cron @reboot su Linux.
5. Inviava una sola volta un rapporto sulla macchina allo stesso server, in HTTP semplice.

Un tunnel inverso va nella direzione opposta rispetto a un normale accesso remoto. La macchina infetta chiama il server dell’attaccante, ed è quella connessione in uscita che un operatore userebbe poi per rientrare. L’avviso di Cursor limita i pacchetti coinvolti a Windows e macOS, anche se i suoi indicatori elencano pure file Linux e Phorion descrive un percorso del codice per Linux.

Il codice aveva anche dei difetti, ha rilevato Phorion. Su macOS lo script controlla Remote Login senza diritti di root, riceve un errore invece della parola «Off» e salta il passaggio di attivazione, ma la chiave e la persistenza finiscono comunque sul disco. L’accesso in ingresso attraverso il tunnel fallisce, allora, a meno che Remote Login fosse già attivo. Phorion sottolinea che non è una difesa, perché la backdoor funziona se l’impostazione viene attivata in seguito. Su Windows una funzione di supporto fissa /bin/sh nel codice, cosa che secondo l’azienda difficilmente funziona su un’installazione standard. Su Linux, un controllo errato di crontab può cancellare i cron job esistenti dell’utente a ogni nuova esecuzione.

La conclusione di Cursor è che sui computer in cui l’attivazione di SSH è fallita l’attaccante «non avrebbe potuto accedere tramite il tunnel». Lo stesso passaggio precisa che l’estensione ha comunque aggiunto la chiave, installato la persistenza e inviato i dettagli del computer, e invita gli utenti a seguire comunque le istruzioni di bonifica.

Il rapporto conteneva i nomi delle variabili d’ambiente, non i valori

Phorion elenca che cosa conteneva il rapporto: nome host, nome utente, sistema operativo e architettura, cartelle home e di lavoro, l’email Git globale, l’indirizzo IP pubblico, indicatori di stato per ogni fase dell’installazione e fino a 40 nomi di variabili d’ambiente corrispondenti a KEY, TOKEN, SECRET, PASS, AWS o GCP. L’elenco di Cursor concorda su nomi, cartelle di lavoro, email Git e IP pubblico.

Phorion è esplicita: il rapporto riportava solo i nomi, il beacon «non esfiltra i valori dei segreti», ha scritto. Nessuna fonte esaminata per questo articolo dice che sia stato inviato un valore.

I nomi dicono comunque qualcosa. Phorion li legge come un inventario che aiuta un operatore a decidere quali macchine privilegiare. Prendiamo due nomi inventati da noi per fare un esempio, che non compaiono in nessuna fonte: una variabile chiamata DEPLOYER_PRIVATE_KEY o EXCHANGE_API_SECRET segnalerebbe un computer degno di maggiore attenzione, anche se il rapporto porterebbe soltanto il nome.

Il limite vale per il rapporto, non per ciò che la backdoor avrebbe potuto consentire in seguito. Lo dice lo stesso Cursor: «La raccolta limitata di variabili d’ambiente non esclude un successivo accesso alle credenziali tramite la backdoor». BleepingComputer osserva che lo script non ruba direttamente le credenziali e lo legge come segno che gli attaccanti intendevano raccogliere a mano i dati sensibili dopo essere entrati. Nessuna fonte che abbiamo letto riferisce un caso di accesso di questo tipo.

Come il pacchetto sia arrivato sul marketplace resta senza spiegazione

L’avviso di Cursor non spiega come il pacchetto manomesso sia stato pubblicato a nome di Anthropic. The Register ha riferito il 30 ottobre che, oltre alla dichiarazione riportata più sotto, né Cursor né Anthropic avevano commentato. BleepingComputer ha indicato la stessa domanda come senza risposta, insieme a quella se i sistemi di Cursor o di Anthropic siano stati violati. Nessuna fonte letta nomina un responsabile.

La posizione di Anthropic ci arriva di seconda mano. The Register ha riportato che Felix Rieseberg, membro dello staff tecnico di Anthropic, ha scritto su X: «Stiamo collaborando con Cursor su questo incidente, ma non è stata una violazione dei sistemi di Anthropic né dei portatili dei dipendenti». Secondo lo stesso resoconto ha aggiunto che «Un malintenzionato ha usato l’accesso al marketplace di Cursor per pubblicare una copia manomessa» dell’estensione, che Anthropic «non ha creato né pubblicato», che le versioni sui suoi canali ufficiali non erano interessate e che lo erano solo gli utenti di Cursor. Coindaro non ha letto il post in prima persona.

È la ricostruzione di Anthropic stessa, e nessuna fonte letta la conferma in modo indipendente. Resta aperto anche come sia stato ottenuto l’accesso al marketplace, e da chi. Reuters, in un dispaccio ripreso dal Gulf Daily News, ha scritto che Anthropic non aveva risposto subito a una richiesta di commento, e BleepingComputer ha detto di aver contattato entrambe le società e che avrebbe aggiornato l’articolo in caso di risposta.

The Register scrive che il post rispondeva a figure della cybersicurezza che avevano sostenuto una violazione in Anthropic; non le nomina né espone le loro prove. L’avviso di Cursor non contiene dichiarazioni di Anthropic. Phorion definisce la scheda l’estensione ufficiale sul Cursor Marketplace, e nessuna fonte letta spiega chi controllasse la pubblicazione su di esso.

Cursor descrive la propria reazione nell’avviso. Ha rimosso la versione malevola, bloccato ulteriori distribuzioni e chiuso temporaneamente il marketplace. Ha poi verificato gli accessi, afferma che nessun’altra estensione è stata manomessa, ha ruotato le chiavi, ricostruito il marketplace e lo ha riaperto. Ha lavorato anche con il fornitore di hosting e dice che il server dell’attaccante è offline. Non segnala prove che altre versioni dell’estensione o la distribuzione ufficiale siano state toccate. Come per la versione di Anthropic, sono dichiarazioni della società stessa. Un server offline non pulisce però una macchina: secondo il codice descritto sopra, la chiave e i job di nuovo tentativo restano finché qualcuno non li rimuove.

Il perimetro è cambiato nei primi due giorni, quindi gli articoli più vecchi possono essere sbagliati. I primi resoconti citavano npm, Open VSX e il Visual Studio Code Marketplace di Microsoft; BleepingComputer dice che in seguito è stato confermato che Cursor era l’unica fonte. Phorion ha corretto il proprio post indicando il marketplace di Cursor il 30 ottobre alle 09:13 UTC. In origine nominava solo la 2.1.313 e ha aggiunto la 2.1.312 il 31 ottobre alle 00:43 UTC, dopo che Cursor aveva aggiornato l’avviso il 30 ottobre alle 11:30, ora del Pacifico (18:30 UTC). The Register e BleepingComputer indicano ancora la sola 2.1.313.

Il numero di persone coinvolte non è accertato. Reuters ha riferito il 30 ottobre che Cursor avrebbe detto che fino a 5.000 utenti erano interessati. The Register e BleepingComputer riportano «fino a 5.000 sviluppatori» senza una fonte, la prima parlando di infetti e la seconda di esposti. L’avviso di Cursor, che abbiamo riaperto il 2 novembre, non indica alcun numero: consideriamo quella cifra non verificata.

Cosa controllare: i passaggi di Cursor per i computer coinvolti

Il consiglio di Cursor vale per chiunque abbia installato o aggiornato a quelle versioni dal suo marketplace su macOS o Windows durante la finestra indicata. Cursor afferma che la chiave e la persistenza sono state installate anche sui computer in cui l’attivazione di SSH è fallita, quindi un passaggio SSH non riuscito non è un motivo per saltare il controllo. L’avviso chiede agli utenti di:

1. Cercare la chiave. Su macOS Cursor indica questo comando: grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted". Il controllo per Windows è una ricerca PowerShell nei file authorized_keys, riportata nell’avviso.
2. Cercare gli indicatori pubblicati nei log degli endpoint, della rete e dell’installazione delle estensioni.
3. Isolare ogni computer che mostri l’esecuzione del payload o l’installazione della backdoor.
4. Rimuovere la chiave non autorizzata, la persistenza e i processi del tunnel, poi decidere se ricostruire il computer.
5. Ruotare le credenziali e le sessioni raggiungibili dai computer interessati, operando da un sistema attendibile.

Se la chiave viene trovata, Cursor dice che la macchina è coinvolta: valgono i passaggi da 3 a 5, e anche il suo script di bonifica. Ce n’è uno per macOS, da eseguire come utente interessato e non come root, e uno per Windows, da lanciare da PowerShell come amministratore. Ciascuno termina con uno stato diverso da zero se qualcosa resta. L’avviso non fornisce un controllo né uno script per Linux; l’elenco di bonifica di Phorion copre gli elementi Linux. Le domande vanno a [email protected].

Gli indicatori principali qui sotto vengono dall’avviso di Cursor, e l’analisi di Phorion li conferma. Gli hash dei file e le impronte delle chiavi SSH sono nell’avviso. Phorion consiglia di controllare anche l’impronta, oltre al commento.

Due servizi usati dal codice per trovare l’IP pubblico, ifconfig.me e api.ipify.org, sono legittimi e da soli non provano nulla. Per capire se qualcuno abbia davvero usato una backdoor, Phorion dice di cercare nei log SSH gli accessi da 127.0.0.1 o ::1 effettuati con quella chiave, perché le sessioni nel tunnel sembrano provenire dalla macchina stessa. Consiglia anche di terminare il ciclo di nuovi tentativi /bin/sh e di verificare che Remote Login non sia stato attivato in modo inatteso.

Le due analisi divergono sulle credenziali. Cursor dice di ruotare ciò che i computer interessati possono raggiungere. Phorion lega la rotazione all’attivazione di SSH o a prove di un accesso in ingresso. Quella di Cursor è la più rigorosa delle due.

I nostri consigli per chi sviluppa in ambito crypto, in aggiunta a quelli di Cursor

Questa sezione è di Coindaro, non di Cursor né di Phorion, e riguarda l’igiene di base, non la risposta a un incidente. Varrebbe con o senza questo episodio.

• Tenete le seed phrase e le chiavi private che controllano fondi reali fuori dalle macchine di sviluppo, come descrive la nostra guida alla sicurezza della seed phrase.
• Usate chiavi usa e getta per i test, così una chiave di prova trapelata non custodisce nulla di valore.
• Date alle chiavi API degli exchange i diritti più ridotti che il lavoro consente e lasciate disattivati i prelievi dove l’exchange offre questa scelta.
• Scaricate gli script di bonifica dalla pagina del fornitore, mai da una copia girata in una chat o in un forum.

Di nuovo un canale fidato, ma stavolta nessuna perdita segnalata

Coindaro ha raccontato vari attacchi recenti passati da una terza parte e non da una blockchain, lo schema descritto nella nostra guida su dove avvengono davvero gli hack crypto. Questo caso condivide il percorso ma, finora, non l’esito. Le cifre della tabella sono quelle riportate in ciascuno dei nostri articoli precedenti.

Fearless Wallet è il più vicino per forma, dato che entrambi sono estensioni, ma conta la differenza: quella prendeva direttamente le chiavi private, mentre questa, sulle prove finora disponibili, ha preso nomi di variabili d’ambiente e ha provato ad aprire una porta. CryptoSlate scrive che nessuno dei due avvisi esaminati stabilisce un furto di crypto o un obiettivo specifico sulle crypto. Qui il bersaglio erano le macchine degli sviluppatori, e nessuna fonte letta collega l’incidente a un gruppo noto o ad altri hack recenti.

Le domande a cui nessuno ha ancora risposto

Al 2 novembre restano aperte diverse questioni. Né Cursor né Anthropic hanno spiegato come l’attaccante abbia ottenuto l’accesso per pubblicare il pacchetto, e nessun numero di installazioni è stato confermato alla fonte. Nessuna fonte letta riferisce di una macchina davvero raggiunta tramite un tunnel, o di una credenziale sottratta. Phorion dice che non è chiaro perché il rapporto sia stato inviato anche a un indirizzo locale, 127.0.0.1 sulla porta 8099.

Cursor ha aggiornato l’avviso per l’ultima volta il 30 ottobre e Phorion la sua analisi il 31 ottobre. Al nostro controllo del 2 novembre nessuna delle due pagine mostrava nulla di più recente.