Una campagna di supply chain attack di nuova generazione non aspetta di essere scoperta: prima si mimetizza, poi colpisce. È questa la logica dietro GlassWorm, un attore malevolo che ha trasformato il marketplace Open VSX in un campo minato di estensioni apparentemente legittime, pronte ad attivarsi dopo settimane di apparente innocenza.
La nuova ondata: 73 estensioni sleeper identificate
Il 25 aprile 2026, i ricercatori di Socket hanno pubblicato un’analisi approfondita rilevando 73 nuove estensioni per Open VSX — il registry alternativo a Visual Studio Marketplace, utilizzato principalmente dagli sviluppatori di VSCodium e Eclipse Theia — che mostrano caratteristiche riconducibili alla campagna GlassWorm. Almeno sei di queste estensioni si sono già “svegliate”, aggiornandosi per distribuire payload malevoli, mentre le restanti rimangono classificate come sleeper ad alta confidenza in attesa di attivazione.
Il meccanismo è elegante nella sua perversità: le estensioni vengono pubblicate con codice pulito, superano i controlli automatici del marketplace, accumulano installazioni e fiducia degli utenti — poi, attraverso un aggiornamento silenzioso o aggiungendo una dipendenza malevola, si trasformano in vettori di malware. Nessun exploit, nessun CVE: pura abuso della fiducia nella supply chain del software.
Evoluzione di una campagna persistente
GlassWorm non è un attore nuovo. La campagna è attiva almeno dal tardo 2024, con escalation progressive che si sono succedute nel corso del 2025-2026. A dicembre 2025 furono rilevate le prime 24 estensioni impersonatrici; a febbraio 2026 si scoprì che un account sviluppatore compromesso era stato usato per propagare il malware; a marzo 2026 la campagna scalò a 72 estensioni attive su Open VSX con diffusione tramite abuso di dipendenze. L’ondata di aprile 2026 rappresenta dunque l’evoluzione più sofisticata finora osservata.
Gli obiettivi rimangono costanti: furto di segreti di sviluppo (API key, token, credenziali), svuotamento di wallet di criptovalute, e trasformazione dei sistemi infetti in proxy per ulteriori attività criminali. Il target primario sono sviluppatori che lavorano su macOS, Linux e Windows con ambienti basati su VS Code o suoi fork.
Tecniche di attacco: la profondità della sleeper strategy
L’analisi di Socket rivela una serie di pattern tecnici ricorrenti nell’attuale cluster di 73 estensioni. I publisher sono account GitHub neonati, con una o due repository pubbliche: una repository vuota con nome composto da otto caratteri casuali e una contenente il codice dell’estensione. Questo pattern serve a superare le verifiche di identità del marketplace, che richiedono un profilo GitHub associato.
Le estensioni impersonano utility popolari — ad esempio il language pack turco per VS Code — usando la stessa icona, un nome simile e contenuti copiati dal pacchetto legittimo. Una volta guadagnata la fiducia degli utenti, la delivery del malware avviene in due modalità principali: aggiornamento diretto dell’estensione per includere codice offuscato, oppure aggiunta di una dipendenza da un’estensione separata che contiene il loader GlassWorm, sfruttando il fatto che l’installazione di un’estensione può portare all’installazione automatica di tutte le sue dipendenze dichiarate.
I payload attivati al momento includono: VSIX malevoli ospitati su GitHub, binari nativi firmati con certificati rubati, JavaScript offuscato con tecniche di code splitting per sfuggire all’analisi statica. Il loader GlassWorm, una volta eseguito nell’ambiente VS Code, ha accesso allo stesso filesystem, alle variabili d’ambiente e ai token di sessione dell’IDE — un privilegio enorme che permette di esfiltrare le credenziali di ogni servizio cloud configurato nello strumento di sviluppo.
Contesto più ampio: l’ecosistema VS Code come vettore sistemico
GlassWorm rappresenta un sintomo di una vulnerabilità strutturale: gli ecosistemi di estensioni per editor di codice sono intrinsecamente difficili da proteggere. A differenza dei package manager come npm o PyPI, dove esiste una cultura più consolidata di analisi della sicurezza, i marketplace di estensioni IDE tendono ad avere meccanismi di revisione più leggeri e una percezione del rischio più bassa da parte degli utenti. Un desarrollatore che installa un’estensione VS Code raramente si chiede se stia introducendo un RAT nella propria workstation.
La tecnica della sleeper extension è particolarmente insidiosa perché richiede pazienza da parte dell’attaccante — una caratteristica tipica di campagne sponsorizzate da attori con risorse significative. Non è ancora stata stabilita un’attribuzione definitiva per GlassWorm, ma il livello di sofisticazione e persistenza suggerisce un gruppo criminale strutturato o un attore nation-state interessato alla compromissione di pipeline di sviluppo software.
Indicatori di compromissione (IoC)
# Pattern publisher malevoli (account GitHub)
- Account con repository vuota a nome di 8 caratteri esadecimali
- Account creati tra gennaio e aprile 2026 senza storia pubblica
# Pattern nomi estensioni sospette (esempi noti)
- Estensioni che impersonano language pack (es. Turkish Language Pack for VSCode)
- Estensioni con nomi che differiscono di un carattere da quelle legittime
# Comportamenti runtime sospetti
- Lettura di variabili d'ambiente (PATH, HOME, credenziali cloud)
- Connessioni in uscita verso bucket S3 su us-east-2 o us-west-2
- Caricamento dinamico di script da URL GitHub Raw
# Repository di tracking
https://socket.dev/glassworm-v2 (lista aggiornata estensioni maligne)Consigli per i difensori
Per chi gestisce ambienti di sviluppo, alcune misure concrete. Prima di tutto, applicare policy di allowlist per le estensioni VS Code/VSCodium approvate, impedendo l’installazione di estensioni non verificate dall’organizzazione. Monitorare con strumenti come Socket o Phylum le dipendenze dei progetti, incluse quelle delle estensioni IDE. Configurare il traffico di rete delle workstation degli sviluppatori per rilevare connessioni anomale verso S3 bucket sconosciuti o hostname Heroku. Abilitare la telemetria degli IDE aziendali e integrarla nel SIEM per rilevare accessi insoliti al keychain o alle variabili d’ambiente. Infine, considerare l’adozione di ambienti di sviluppo containerizzati o in sandbox, dove l’impatto di un’estensione compromessa è limitato al container.
Socket mantiene una pagina dedicata al tracking di GlassWorm v2 con l’elenco aggiornato delle estensioni malevole identificate: consultarla periodicamente è una misura di igiene minima per chi usa Open VSX. La campagna è ancora attiva e il numero di sleeper non ancora attivati — stimato in oltre 60 — suggerisce che il peggio non sia ancora avvenuto.