La backdoor non era in Claude. Era nella fiducia nel marketplace

La parte più interessante di questa storia non è che qualcuno abbia tentato di installare una backdoor SSH su un computer. È il punto in cui ha provato a farlo: un’estensione per programmatori, distribuita con il nome di un prodotto conosciuto, caricata dentro un editor che molti usano anche per lavorare su server, repository e credenziali. Non serviva convincere Claude a rispondere male. Bastava che l’editor eseguisse un file JavaScript.

Il 29 ottobre 2026 il marketplace di Cursor ha distribuito copie manomesse dell’estensione anthropic.claude-code. La prima notizia parlava della versione 2.1.313; l’avviso di sicurezza aggiornato di Cursor include anche la 2.1.312, nelle build macOS e Windows. Non è una sfumatura: in un incidente di supply chain il numero di versione, da solo, non identifica necessariamente il file che è stato davvero installato.

Undici ore, due versioni e un confine preciso

La finestra dichiarata da Cursor va dalle 02:27 alle 13:35 del 29 ottobre, ora del Pacifico, cioè dalle 09:27 alle 20:35 UTC. L’azienda indica un massimo di 5.000 utenti potenzialmente coinvolti, ai quali ha annunciato un contatto diretto. Non significa 5.000 computer controllati dall’attaccante. Non significa nemmeno che chiunque abbia installato Claude Code 2.1.312 o 2.1.313 sia stato colpito.

Il perimetro documentato riguarda le copie scaricate o aggiornate dal Cursor Extension Marketplace in quella finestra, su macOS e Windows. Cursor e StepSecurity, che ha aggiornato la propria analisi dopo le prime attribuzioni, distinguono quelle build dalle distribuzioni ufficiali di Anthropic e dagli artefatti puliti degli altri canali. Non abbiamo evidenza che i sistemi di Anthropic o il Microsoft VS Code Marketplace siano stati compromessi. Il modo in cui il pacchetto alterato sia entrato nella distribuzione di Cursor resta un punto da chiarire.

Questo dettaglio è essenziale, soprattutto quando una notizia tecnica comincia a circolare con titoli che trasformano un incidente circoscritto in un presunto attacco riuscito a tutta Anthropic. Se sbagliamo il confine dell’incidente, sbagliamo anche la risposta: controlliamo le macchine sbagliate, cerchiamo indicatori inutili e magari lasciamo fuori quelle realmente esposte.

L’estensione non doveva aspettare una domanda all’AI

Il file alterato era extension.js, l’entry point dell’estensione. I ricercatori hanno individuato un piccolo loader aggiunto davanti al bundle legittimo. Secondo la ricostruzione tecnica aggiornata di StepSecurity, il codice malevolo occupava circa 7,4 KB ed era eseguito quando il modulo veniva caricato, prima della normale inizializzazione dell’estensione. Nessun prompt, nessuna chat con Claude, nessuna richiesta esplicita di eseguire un comando.

La sequenza osservata nel codice era concreta. Raccoglieva informazioni sulla macchina e sull’utente, inclusi nomi di variabili d’ambiente potenzialmente associate a credenziali; provava ad aggiungere una chiave SSH controllata dall’attaccante in authorized_keys; tentava di attivare il servizio SSH e aprire un tunnel inverso; preparava meccanismi di persistenza e inviava un rapporto sullo stato della macchina a un endpoint HTTP. I nomi delle variabili non sono i loro valori, ma possono comunque indicare quali sistemi e quali tipi di segreti esistono su quell’host.

Non è la stessa cosa di un modello AI che decide autonomamente di fare qualcosa di pericoloso. Qui il modello non è il vettore. Il vettore è il codice eseguibile di un’estensione. E un’estensione IDE, per svolgere il proprio lavoro, opera spesso con gli stessi privilegi dell’utente che ha aperto l’editor.

La domanda non è soltanto se ti fidi dello sviluppatore dell’estensione. È se puoi verificare quale artefatto ti sta consegnando il canale che hai scelto per installarla.

Una backdoor che fallisce non è una macchina automaticamente pulita

C’è un secondo elemento che rende questo incidente interessante: il payload aveva errori. Cursor spiega che l’attivazione del servizio SSH richiedeva privilegi amministrativi che l’estensione, sui normali host macOS e Windows, non possedeva. In quelle condizioni il passaggio necessario a rendere raggiungibile il servizio falliva e l’attaccante non poteva entrare attraverso quel tunnel. È una limitazione reale, non un dettaglio da nascondere per rendere più drammatico il racconto.

Ma gli altri passaggi potevano essere già avvenuti. La chiave non autorizzata poteva essere stata aggiunta, gli script di persistenza potevano essere rimasti sul disco e i dati di ricognizione potevano essere stati inviati. Un errore nell’ultima parte della catena non cancella retroattivamente le prime. La valutazione di Sophos X-Ops raccomanda infatti di cercare gli indicatori, rimuovere i meccanismi persistenti e considerare la rotazione delle credenziali accessibili dall’host.

La distinzione corretta è tra esposizione al pacchetto, esecuzione del codice e accesso remoto riuscito. Sono tre eventi diversi, da dimostrare con prove diverse. Confonderli porta a due errori opposti: dichiarare migliaia di vittime confermate oppure liquidare l’incidente perché il tunnel, su molti sistemi, non si è aperto.

La provenienza conta più dell’etichetta

Il nome anthropic.claude-code sembrava quello giusto. L’interfaccia dell’estensione continuava a funzionare. E il codice legittimo era ancora lì, dopo il loader. Dal punto di vista dell’utente, molti segnali superficiali suggerivano normalità. Proprio per questo la fiducia non può ridursi al nome del publisher o a un’icona verificata.

Bisogna separare almeno quattro cose: il sorgente che il produttore intende distribuire, l’artefatto compilato o impacchettato, il registro che lo pubblica e il client che lo scarica. Se un passaggio sostituisce i byte, il nome del pacchetto può restare identico mentre cambia completamente il rischio. La versione è un metadato; l’hash identifica i byte; la provenienza e la catena di attestazione spiegano da dove arrivano quei byte. Nessuno di questi controlli, isolato dagli altri, è una garanzia assoluta.

È un problema vicino a quello che ho già analizzato parlando dei repository che possono eseguire codice prima che tu li abbia davvero letti. Lì il confine era il workspace e i suoi hook. Qui è il marketplace. In entrambi i casi il punto pericoloso precede l’interazione che l’utente considera significativa: il comando dell’agente, la chat, il test o il clic.

Se hai usato Cursor il 29 ottobre, il controllo è sul computer

La prima verifica è ricostruire da dove è stata installata l’estensione, quale artefatto è arrivato e quando. Una versione numerica uguale a quella segnalata non è una prova sufficiente, soprattutto dopo che i ricercatori hanno chiarito le differenze tra i canali di distribuzione.

Per gli host potenzialmente esposti, Cursor pubblica indicatori e procedure di bonifica per macOS e Windows. Tra gli indicatori compare una chiave SSH non autorizzata con commento svc-telemetry in authorized_keys. Il controllo di quella stringa è un punto di partenza utile, ma l’assenza del marcatore non dimostra da sola che non sia successo nulla: vanno considerate anche telemetria delle installazioni, processi, connessioni e artefatti di persistenza.

• Contieni e conserva le prove: se trovi indicatori di esecuzione o persistenza, isola l’host e acquisisci i log utili prima di cancellare tutto alla cieca.
• Rimuovi l’intera catena: estensione alterata, chiave SSH non autorizzata, processi e script persistenti. Segui le procedure aggiornate pubblicate da Cursor, verificandone la provenienza.
• Verifica l’accesso: controlla i log SSH e di rete, le sessioni e le attività successive; non assumere che l’assenza del tunnel oggi escluda un accesso passato.
• Ruota da un sistema fidato: credenziali, token e sessioni potenzialmente raggiungibili dall’account interessato, calibrando l’intervento sulle evidenze.

Il server di comando e controllo identificato nell’avviso è stato disattivato, secondo Cursor. È una mitigazione importante, non un ripristino automatico della fiducia nel computer. E disinstallare o aggiornare l’estensione non rimuove necessariamente file e meccanismi di persistenza che il payload aveva già scritto.

Il controllo serio inizia prima del prossimo aggiornamento

La risposta organizzativa non può essere semplicemente “non installare estensioni”. Sarebbe una conclusione facile e poco utile: un ambiente di sviluppo vive di dipendenze, toolchain, editor, agenti e integrazioni. Il problema è decidere come autorizzarle, inventariarle e verificarle. Per i sistemi più sensibili significa controllare provenienza e hash degli artefatti, limitare l’installazione automatica non governata, separare gli account di sviluppo dai privilegi amministrativi, proteggere chiavi e sessioni e avere log sufficienti per ricostruire cosa è stato eseguito.

Significa anche accettare che l’aggiornamento non è solo un’operazione di manutenzione. È una nuova consegna di codice eseguibile. Ne ho parlato, da un’altra prospettiva, a proposito di WordPress e della superficie d’attacco durante un aggiornamento: il punto non è avere paura delle patch, ma sapere quali verifiche devono accompagnare la distribuzione.

In questo caso Cursor ha rimosso le build alterate, sospeso temporaneamente il marketplace, ricostruito l’infrastruttura e ruotato le proprie chiavi, secondo la comunicazione ufficiale. Sono azioni di risposta documentate. Non ci dicono ancora come sia avvenuto l’inserimento iniziale. Ed è proprio quella parte che servirà a valutare quali controlli di pubblicazione abbiano fallito.

Il modello non può garantire la sicurezza del sistema che lo ospita

Siamo così abituati a discutere di sicurezza degli agenti AI come se tutto iniziasse e finisse nel prompt che rischiamo di ignorare il resto. Ma prima che un modello suggerisca un comando ci sono un editor, un processo, delle librerie, una catena di aggiornamento, un account utente e spesso una collezione di credenziali pronte all’uso.

Se uno di quei passaggi esegue codice non verificato, il modello può anche comportarsi perfettamente: il danno è già possibile. La lezione del 29 ottobre non è che Claude sia diventato malevolo. È che abbiamo concesso a un marketplace una parte della fiducia che riserviamo al nostro ambiente di lavoro, senza sempre trattarlo come un componente critico dell’infrastruttura.

Un sistema affidabile non nasce da un marchio noto, da una spunta sullo store o da un aggiornamento automatico. Nasce dalla capacità di stabilire quali byte sono arrivati, chi li ha autorizzati, con quali privilegi sono stati eseguiti e come verificare che, dopo un incidente, non sia rimasto aperto nulla.