Sintesi

È stata recentemente rilevata la distribuzione di versioni malevole dell’estensione Anthropic.claude-code all’interno del “Cursor VS Code Extension Marketplace”, che ha comportato la raccolta e l’esfiltrazione di informazioni di sistema e sull’ambiente di lavoro degli host e il tentativo di installazione di una backdoor SSH persistente sui dispositivi degli sviluppatori. L’attacco è stato veicolato tramite versioni opportunamente predisposte del componente per sistemi operativi Windows e macOS, non sviluppate da Anthropic. Allo stato, non risultano evidenze di compromissione relative alla distribuzione ufficiale dell’estensione né ad altri pacchetti ospitati sulla piattaforma.

Descrizione

Cursor ha rilevato un incidente di sicurezza sul proprio marketplace delle estensioni, avvenuto in data 29 ottobre 2026 e riconducibile alla pubblicazione di due versioni malevole dell’estensione “Claude Code” (identificata come Anthropic.claude-code , versioni 2.1.312 e 2.1.313) per ambienti Windows e macOS.

Le versioni compromesse dell’estensione sono rimaste disponibili per il download sul Cursor VS Code Extension Marketplace per una finestra temporale di circa 11 ore (tra le 02:27 e le 13:35 PT, corrispondenti all’intervallo 09:27 – 20:35 UTC del 29 ottobre 2026). All’avvio dell’IDE, il codice malevolo inserito all’interno del file extension.js eseguiva attività di ricognizione raccogliendo informazioni sull’host e sull’utente — tra cui hostname, username, sistema operativo, architettura, percorso della home directory, nomi delle variabili d’ambiente, directory di lavoro, indirizzo e-mail configurato su Git e indirizzo IP pubblico — trasmettendole tramite richieste HTTP POST verso un endpoint remoto controllato dall’attaccante ( 134[.]209[.]82[.]225:8099/beacon ).

Contestualmente, il payload tentava di stabilire un accesso remoto persistente aggiungendo una chiave pubblica SSH controllata dall’attaccante (identificata dal commento svc-telemetry ) al file authorized_keys locale e tentando al tempo stesso di abilitare il servizio SSH di sistema, al fine di instaurare successivamente un tunnel SSH inverso verso l’infrastruttura dell’attaccante ( tunnel@134[.]209[.]82[.]225 sulla porta TCP 22), con l’obiettivo di esporre il servizio SSH locale del sistema compromesso. Per mantenere attivo il canale di comunicazione con tentativi di riconnessione ogni 60 secondi, l’estensione installava appositi meccanismi di persistenza: su macOS tramite il LaunchAgent ~/Library/LaunchAgents/com.apple.sysmond.plist e script nascosti in ~/.config/.smt , mentre su Windows mediante la creazione di un’attività pianificata denominata SysMon (configurata per tentare l’esecuzione con privilegi SYSTEM) e uno script di fallback nel percorso di avvio automatico ( %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd ).

L’abilitazione del demone SSH locale richiede tuttavia privilegi amministrativi che il processo dell’IDE non possiede nelle configurazioni predefinite di macOS e Windows. Pertanto, salvo i casi in cui l’IDE sia stato avviato manualmente con privilegi elevati, a causa di errori di programmazione nel codice malevolo l’attivazione del servizio SSH è fallita sulla maggior parte degli host. Questo ha ridotto sensibilmente la probabilità che l’attaccante potesse ottenere un accesso remoto in modo interattivo attraverso il tunnel, pur avendo ottenuto i metadati dell’host e lasciando sul sistema la chiave SSH non autorizzata e i meccanismi di persistenza installati.

Conclusioni

L’evento conferma il progressivo aumento delle minacce di tipo Supply Chain Attack che prendono di mira gli strumenti di lavoro e gli ambienti di sviluppo integrati (IDE) utilizzati dal personale tecnico. La fiducia implicita riposta nei marketplace integrati e l’adozione di meccanismi di aggiornamento automatico (auto-update) senza validazione preventiva consentono agli aggressori di aggirare i tradizionali meccanismi di fiducia legati alle fonti software considerate legittime. Sebbene i limiti dei privilegi del sistema operativo abbiano in questo caso limitato l’attivazione del servizio di accesso remoto interattivo sulle postazioni standard, la capacità del payload di installare script di persistenza autonomi ed esfiltrare dati di configurazione evidenzia la necessità di estendere anche alle singole postazioni degli sviluppatori i controlli sulla postura di sicurezza, il monitoraggio dei processi locali e la verifica dell’integrità del software.

Prodotti e versioni affette

La compromissione ha interessato in modo specifico le versioni modificate 2.1.312 e 2.1.313 dell’estensione “Claude Code” ( Anthropic.claude-code ) per piattaforme Windows (win32-x64) e macOS (darwin-arm64), distribuite esclusivamente tramite il “Cursor VS Code Extension Marketplace” nella giornata del 29 ottobre 2026. Sono potenzialmente esposti tutti gli endpoint di sviluppo in cui l’estensione è stata installata o aggiornata durante la finestra di esposizione temporale sopra indicata.

Azioni di mitigazione

Cursor ha dichiarato di aver rimosso immediatamente le versioni compromesse dal marketplace, sospeso temporaneamente il catalogo per verifiche di integrità su tutte le altre estensioni, ruotato le proprie chiavi crittografiche, ricostruito l’infrastruttura del marketplace e collaborato con il provider di hosting per disattivare il server di comando e controllo dell’attaccante.

Per gli utenti e le organizzazioni che utilizzano il medesimo ecosistema di sviluppo, si raccomanda l’adozione delle seguenti procedure di verifica e contenimento:

• Esaminare i log dei sistemi aziendali, la telemetria di rete (connessioni verso l’IP 134[.]209[.]82[.]225 sulle porte TCP 22 e 8099) e le postazioni degli sviluppatori per verificare l’eventuale installazione o aggiornamento delle versioni 2.1.312 e 2.1.313 dell’estensione Anthropic.claude-code nella finestra temporale critica del 29 ottobre 2026.
• Controllare la presenza della chiave pubblica SSH dell’attaccante (identificata dal commento svc-telemetry e dal fingerprint SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk ) all’interno dei file ~/.ssh/authorized_keys su macOS/Linux o %USERPROFILE%\.ssh\authorized_keys e C:\ProgramData\ssh\administrators_authorized_keys su Windows. Per lo scopo, valutare l’esecuzione dei seguenti comandi suggeriti dal vendor:
  
  • macOS:

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

  • WINDOWS:

    $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" }

• Isolare gli endpoint che presentano evidenze di esecuzione del payload e procedere alla rimozione della chiave SSH non autorizzata, dei processi di tunnel ( ssh / autossh ) e dei meccanismi di persistenza ( com.apple.sysmond.plist , task pianificato SysMon , script ~/.config/.smt,%USERPROFILE%\.config\smt.cmd e sysmon.cmd ), avvalendosi degli script di bonifica ufficiali forniti dal vendor e valutando il ripristino completo (rebuild) dell’host, poiché la semplice disinstallazione dell’estensione non rimuove gli script standalone depositati sul sistema.
• Procedere, operando da una postazione fidata, alla revoca e alla rotazione di tutte le credenziali, chiavi SSH, token di sessione e credenziali e chiavi delle applicazioni accessibili dai dispositivi impattati.
• Disabilitare la funzionalità di aggiornamento automatico per i plugin e le estensioni degli IDE aziendali e applicare rigorosamente il principio del minimo privilegio (Least Privilege) sui dispositivi di sviluppo, evitando l’esecuzione degli ambienti IDE con privilegi di amministratore e segregando l’accesso alle chiavi di produzione e ai token CI/CD.
• Al momento della pubblicazione del presente bollettino, Cursor ha comunicato che il server dell’attaccante (134[.]209[.]82[.]225) è stato disattivato in collaborazione con il provider di hosting e non risulta più operativo; tale circostanza non esclude tuttavia la necessità di verificare l’eventuale presenza dei meccanismi di persistenza installati sui sistemi precedentemente esposti.

Infine, si raccomanda di valutare l’implementazione, sui propri apparati di sicurezza, degli Indicatori di Compromissione (IoC) [1] disponibili all’interno del bollettino di sicurezza riportato nella sezione Riferimenti.

[1] Per definizione, non tutti gli indicatori di compromissione sono malevoli. Questo CSIRT non ha alcuna responsabilità per l’attuazione di eventuali azioni proattive (es. inserimento degli IoC in blocklist) relative agli indicatori forniti. Le informazioni contenute in questo documento rappresentano la migliore comprensione della minaccia al momento del rilascio.