A metà marzo 2026, il team di ricerca di Socket ha reso pubblica una delle campagne di supply-chain attack più sofisticate mai registrate nel mondo degli IDE: GlassWorm. In totale, 72 estensioni malevole caricate sul marketplace Open VSX, 151 repository GitHub compromessi, 10 pacchetti npm infetti e oltre 9 milioni di installazioni stimate. Nella mia carriera di sysadmin ho visto attacchi mirati a server, CMS e container, ma questa campagna ha colpito direttamente l’ambiente di lavoro degli sviluppatori — l’IDE — trasformando la fiducia nel codice open source in un vettore di attacco.
Quello che rende GlassWorm particolarmente insidioso è il meccanismo di propagazione: non si tratta di estensioni palesemente malevole, ma di strumenti apparentemente legittimi — linter, formatter, code runner, persino assistenti AI per Claude Code e Google Antigravity — che dopo aver guadagnato la fiducia dell’utente, si aggiornano silenziosamente per includere dipendenze transitive contenenti il payload malevolo.
In questo articolo vi racconto la cronologia dell’attacco, i dettagli tecnici, gli indicatori di compromissione e soprattutto come verifico la sicurezza delle mie estensioni VS Code dopo questa scoperta. Se gestite server, sviluppate plugin o semplicemente usate VS Code quotidianamente, queste informazioni sono essenziali.
Cronologia dell’Attacco GlassWorm: Da Ottobre 2025 a Marzo 2026
GlassWorm non è apparso dal nulla. La prima segnalazione risale a ottobre 2025, quando i ricercatori di Koi Security identificarono comportamenti anomali in alcune estensioni Open VSX. La campagna è poi evoluta in più ondate:
- Ottobre 2025: prima osservazione del malware GlassWorm da parte di Koi Security
- Novembre 2025 – Gennaio 2026: fase di espansione silenziosa con 50 transazioni Solana documentate per aggiornare gli URL dei payload
- 31 Gennaio 2026: scoperte le prime estensioni Open VSX malevole della nuova ondata
- 3-9 Marzo 2026: campagna massiva di iniezione su 151 repository GitHub
- 8 Febbraio 2026: il ricercatore Oran Simhony di Koi Security segnala la vulnerabilità “Open Sesame” nel sistema di scansione pre-pubblicazione di Open VSX
- 13 Marzo 2026: il Socket Research Team pubblica l’analisi completa delle 72 estensioni malevole
- 17 Marzo 2026: divulgazione pubblica coordinata da Bleeping Computer, The Hacker News e altri
La Portata dell’Attacco: 433 Componenti Compromessi
L’analisi congiunta di Socket, Aikido, Step Security, Truesec e la community OpenSourceMalware ha rivelato una campagna su scala massiva con 433 componenti compromessi distribuiti su più piattaforme:
- 200 repository GitHub in Python (con force-push di commit malevoli)
- 151 repository GitHub in JavaScript/TypeScript
- 72 estensioni Open VSX (usato da Cursor, Windsurf, Trae e altri fork di VS Code)
- 10 pacchetti npm con tecnica di Unicode injection
Le estensioni malevole imitavano utility di sviluppo molto diffuse. Tra quelle identificate: angular-studio.ng-angular-extension, gvotcha.claude-code-extension, mswincx.antigravity-cockpit e turbobase.sql-turbo-tool. La scelta dei nomi non è casuale: puntano esattamente ai tool che gli sviluppatori cercano quotidianamente.
Come Funziona Tecnicamente GlassWorm: Dipendenze Transitive e Unicode Invisibile
Il cuore dell’attacco si basa su due tecniche combinate che lo rendono quasi impossibile da individuare con una revisione visuale del codice.
Abuso delle Dipendenze Transitive
L’attaccante pubblica un’estensione apparentemente pulita su Open VSX. Una volta che l’estensione accumula installazioni e fiducia, viene rilasciato un aggiornamento che introduce un campo extensionPack o extensionDependencies nel manifest, puntando a un’estensione separata contenente il loader GlassWorm. Quando l’IDE installa o aggiorna l’estensione principale, scarica automaticamente anche le dipendenze — incluso il payload malevolo.
Caratteri Unicode Invisibili
Il payload vero e proprio è codificato usando caratteri Unicode invisibili — variation selector (U+FE00-U+FE0F e U+E0100-U+E01EF), caratteri zero-width e controlli bidirezionali. Questi caratteri non producono alcun output visivo nell’editor di codice o nel terminale, ma una volta decodificati si trasformano in un loader che scarica ed esegue uno script di secondo stadio. Anche le diff di GitHub possono non evidenziare queste modifiche.
Infrastruttura C2 a Triplo Livello
GlassWorm utilizza un’architettura command-and-control resiliente su tre livelli:
- Blockchain Solana: il malware interroga transazioni Solana ogni 5 secondi come “dead drop resolver” per ottenere l’indirizzo C2 aggiornato (wallet:
28PKnu7RzizxBzFPoLp69HLXp9bJL3JFtT2s5QzHsEA2). Questa infrastruttura non può essere abbattuta con un semplice takedown - IP diretto: server primario
217.69.3.218per il download dei payload - Google Calendar: canale C2 di backup che sfrutta un servizio legittimo per evadere il filtraggio di rete
Cosa Ruba GlassWorm
Una volta attivo, il malware è un vero coltellino svizzero del furto di credenziali:
- Token di autenticazione: NPM, GitHub, Git, Open VSX, CI/CD
- Chiavi SSH e dati di configurazione Git
- Wallet di criptovalute: prende di mira 49 diverse estensioni di wallet crypto
- Variabili d’ambiente e segreti di sistema
- Installa server VNC nascosti per accesso remoto completo
- Deploya proxy SOCKS che trasformano la macchina dello sviluppatore in infrastruttura criminale
Un dettaglio interessante: il malware evita i sistemi con locale russo, un comportamento tipico dei gruppi di minaccia est-europei che evitano di colpire sistemi nei paesi della CSI.
La Vulnerabilità “Open Sesame”: Il Bug che Ha Facilitato l’Attacco
A rendere tutto più grave, il ricercatore Oran Simhony di Koi Security ha scoperto una vulnerabilità critica nel sistema di scansione pre-pubblicazione di Open VSX, ribattezzata “Open Sesame”. Il problema risiedeva nella pipeline Java di scansione:
Il sistema utilizzava un singolo valore booleano per indicare sia “nessuno scanner configurato” che “tutti gli scanner hanno fallito”. Come ha spiegato Simhony: “The pipeline had a single boolean return value that meant both ‘no scanners are configured’ and ‘all scanners failed to run'”.
Un attaccante con un account publisher gratuito poteva inondare l’endpoint con molteplici file .VSIX malevoli, esaurendo il pool di connessioni al database e causando il fallimento dei job di scansione — che il sistema interpretava come validazione riuscita. La vulnerabilità è stata corretta in Open VSX versione 0.32.0 rilasciata a marzo 2026, dopo la segnalazione responsabile dell’8 febbraio.
La lezione è universale e vale per qualsiasi pipeline di validazione: mai far condividere lo stesso valore di ritorno a “nessun lavoro necessario” e “il lavoro è fallito”.
Come Verifico la Sicurezza delle Mie Estensioni VS Code
Dopo la scoperta di GlassWorm, ho rivisto completamente il mio approccio alla sicurezza delle estensioni IDE. Ecco la procedura che seguo ora su tutte le mie macchine di sviluppo e sui server che gestisco.
1. Scansione con anti-trojan-source
Il primo strumento che ho adottato è anti-trojan-source, raccomandato anche da Snyk. Rileva 277 caratteri Unicode confondibili, inclusi i variation selector e i caratteri zero-width usati da GlassWorm:
npm install -D anti-trojan-source
npx anti-trojan-source --files='src/**/*.{js,ts,jsx,tsx}'
# Per output dettagliato con posizione esatta dei caratteri sospetti:
npx anti-trojan-source --files='src/**/*.js' --verbose
# Per output JSON (integrazione CI/CD):
npx anti-trojan-source --files='**/*.{js,ts,py,java,go,rs}' --json2. Controllo degli Indicatori di Compromissione GlassWorm
Step Security ha identificato marker specifici da cercare:
- Cerca la variabile marker
lzcdrtfxyqiplpdnel codice sorgente - Verifica la presenza del file
~/init.json(meccanismo di persistenza) - Controlla installazioni inattese di Node.js nella home directory
- Esamina la cronologia dei commit Git per anomalie (date del committer significativamente più recenti delle date dell’autore)
- Ispeziona file
i.jssospetti nei progetti clonati
3. Audit delle Estensioni Installate
Verifico regolarmente le estensioni installate con questi criteri:
- Controllo le modifiche version-to-version, in particolare l’aggiunta di campi
extensionPackeextensionDependencies - Verifico il publisher e la sua reputazione
- Rimuovo le estensioni non più utilizzate
- Disabilito gli aggiornamenti automatici per le estensioni critiche
4. Monitoraggio del Traffico di Rete
GlassWorm comunica con endpoint specifici. Monitoro le connessioni in uscita dall’IDE cercando:
- Connessioni verso
217.69.3.218(C2 primario) - Connessioni verso
140.82.52.31:80/wall(esfiltrazione) - Query verso servizi blockchain Solana non previsti
- Connessioni anomale a Google Calendar API da processi VS Code
5. Rotazione Preventiva delle Credenziali
Se sospetto anche minimamente una compromissione, la prima cosa che faccio è ruotare tutti i token e le credenziali:
- Token NPM e GitHub Personal Access Token
- Credenziali Git memorizzate localmente
- Chiavi SSH
- Token di pubblicazione Open VSX
- Eventuali chiavi API esposte nelle variabili d’ambiente
6. Integrazione nella CI/CD
Ho aggiunto la scansione Unicode come step obbligatorio nei miei workflow. Ecco un esempio per GitHub Actions:
name: Unicode Security Scan
on: [pull_request, push]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
- run: npx anti-trojan-source --files='**/*.{js,ts,py,java,go,rs}' --jsonQuesto blocca qualsiasi pull request che contiene caratteri Unicode sospetti prima del merge.
La Lezione per Chi Gestisce Server e Sviluppa Plugin
GlassWorm dimostra che la supply chain degli sviluppatori è il nuovo perimetro da difendere. Se come me monitorate le vulnerabilità zero-day sui vostri server, dovete applicare lo stesso rigore alle estensioni del vostro IDE. Un’estensione compromessa su una macchina di sviluppo può portare al furto di token CI/CD, che a loro volta possono compromettere l’intera pipeline di deploy.
Chi sviluppa plugin WordPress — come faccio io — deve prestare particolare attenzione: i token GitHub e le credenziali npm rubati possono essere usati per iniettare codice malevolo direttamente nei repository dei vostri plugin, compromettendo la catena di distribuzione fino agli utenti finali.
E per chi gestisce infrastrutture server, ricordate che la difesa proattiva con monitoraggio continuo non deve limitarsi ai server in produzione: anche le workstation degli sviluppatori sono target primari.
FAQ
Come faccio a sapere se le mie estensioni VS Code sono state compromesse da GlassWorm?
Cerca la variabile marker lzcdrtfxyqiplpd nel tuo codice, verifica la presenza del file ~/init.json e controlla installazioni inattese di Node.js nella home. Usa npx anti-trojan-source --files='**/*.{js,ts}' --verbose per scansionare caratteri Unicode invisibili. Monitora anche le connessioni di rete verso gli IP 217.69.3.218 e 140.82.52.31.
Sono a rischio anche se uso VS Code dal marketplace ufficiale Microsoft e non Open VSX?
Sì, anche se in misura minore. GlassWorm ha colpito principalmente Open VSX (usato da fork come Cursor, Windsurf e Trae), ma la campagna ha compromesso anche pacchetti npm e repository GitHub. Se installi dipendenze npm o cloni repository da GitHub, potresti essere esposto. Microsoft ha introdotto la scansione dei segreti pre-pubblicazione, ma nessun marketplace è immune al 100%.
Cosa devo fare immediatamente se scopro un’estensione GlassWorm installata?
Disinstalla subito l’estensione, disconnetti la macchina dalla rete se possibile e ruota immediatamente tutti i token: GitHub PAT, npm auth, chiavi SSH, credenziali Git, token CI/CD e qualsiasi chiave API nelle variabili d’ambiente. Verifica la cronologia dei commit nei tuoi repository per push non autorizzati. Controlla i processi in esecuzione per eventuali server VNC nascosti o proxy SOCKS.
La vulnerabilità “Open Sesame” di Open VSX è stata risolta?
Sì, la vulnerabilità è stata corretta in Open VSX versione 0.32.0 rilasciata a marzo 2026, dopo la segnalazione responsabile del ricercatore Oran Simhony di Koi Security l’8 febbraio 2026. Il bug consentiva di bypassare la scansione pre-pubblicazione esaurendo il pool di connessioni al database, facendo interpretare al sistema il fallimento degli scanner come validazione riuscita.
Quali strumenti posso integrare nella mia pipeline CI/CD per proteggermi da attacchi simili?
Integra anti-trojan-source come step obbligatorio nelle GitHub Actions per bloccare codice con Unicode sospetto. Usa eslint-plugin-anti-trojan-source per warning in tempo reale nell’IDE. Adotta piattaforme di analisi statica come Snyk o Socket per il monitoraggio continuo delle dipendenze. Implementa la verifica dei checksum sugli aggiornamenti delle estensioni e mantieni una allowlist delle estensioni approvate.
Conclusione
L’attacco GlassWorm del marzo 2026 segna un punto di svolta nella sicurezza della supply chain degli sviluppatori. Con 433 componenti compromessi su GitHub, npm e Open VSX, e un’architettura C2 basata su blockchain Solana praticamente impossibile da abbattere, siamo di fronte a un livello di sofisticazione che richiede un cambio di mentalità.
Non basta più fidarsi del marketplace: ogni estensione va verificata, ogni aggiornamento va controllato, ogni credenziale va considerata potenzialmente esposta. Come chi implementa SOC autonomi e threat prediction, dobbiamo portare lo stesso approccio proattivo anche sul nostro ambiente di sviluppo locale.
Il mio consiglio: partite oggi con la scansione anti-trojan-source, controllate gli indicatori di compromissione, ruotate le credenziali e integrate la verifica nella vostra CI/CD. La sicurezza delle estensioni IDE non è più un optional — è una necessità. Se avete domande o volete condividere la vostra esperienza con GlassWorm, lasciate un commento qui sotto.