GlassWorm: worm auto-propagante nelle estensioni di Visual Studio Code

GlassWorm è un worm auto-propagante che infetta le estensioni di Visual Studio Code e che può diffondersi nella supply chain di sviluppo.

Il 17 ottobre 2025 è stato il giorno in cui qualcosa ha cambiato il modo di intendere gli IDE per sempre. Qualcosa di insolito ha iniziato a circolare tra alcune estensioni di Visual Studio Code. Da sempre considerate innocue e sicure, queste hanno inizato a comportarsi in maniera anomala, presentando aggiornamenti improvvisi, processi che si replicano e tracce di codice che nessuno ricorda di aver scritto.
All’inizio gli sviluppatori parlano di possibile bug a monte, ma gli analisti intuiscono che si tratta di altro.

1. Cos’è GlassWorm
2. Come funziona GlassWorm
3. Come difendersi da GlassWorm

Nei giorni successivi emerge una verità che modifica radicalmente la percezione della sicurezza nello sviluppo software. Un codice malevolo e capace di diffondersi da solo, ha trasformato l’ambiente di lavoro più usato al mondo in un vettore di infezione. Il suo nome? GlassWorm, un worm di nuova generazione che mira direttamente alla supply chain. Per la prima volta, il rischio non arriva da fuori, ma nasce all’interno degli strumenti che usiamo per costruire il software.

Ma come sempre, andiamo con ordine e affrontiamo per gradi l’argomento.

Cos’è GlassWorm

GlassWorm è un worm auto-propagante scoperto il 17 ottobre 2025 dai ricercatori di Truesec e Koi Security. A differenza dei worm tradizionali, non sfrutta falle di sistema o allegati malevoli, ma si diffonde attraverso le estensioni di Visual Studio Code. Una volta installato, replica sé stesso all’interno di altri progetti, contaminando nuovi ambienti di sviluppo e trasformando ogni workstation in un potenziale nodo di propagazione.

L’infezione avviene tramite la modifica dei file di configurazione dell’estensione, dove viene iniettato codice JavaScript offuscato. Questo codice è progettato per auto-replicarsi, per cui ogni progetto aperto in Visual Studio Code può diventare un veicolo di diffusione verso altri repository, ambienti o colleghi di team. Il worm non mira al furto immediato di dati, ma alla creazione di una rete distribuita di sistemi infetti, in grado di aggiornarsi e comunicare autonomamente.

Secondo Truesec, GlassWorm è il primo caso documentato di worm in grado di sfruttare il meccanismo di aggiornamento delle estensioni come canale di diffusione. La sua struttura modulare e la gestione dei comandi tramite infrastruttura decentralizzata ne aumentano la capacità di eludere i controlli. Si tratta di un esperimento che ridefinisce il confine tra strumento di lavoro e superficie d’attacco.

Come funziona GlassWorm

Come detto in precedenza, GlassWorm entra nell’ambiente di sviluppo tramite estensioni Visual Studio Code compromesse o malevole, che vengono installate o aggiornate come componenti leciti. L’obiettivo è trovare ambienti dove queste sono ampiamente usate e dove i flussi di lavoro prevedono condivisione rapida di snippet, template o pacchetti.

Una volta eseguita, l’estensione modifica file di progetto e script locali in modo non appariscente, inserendo porzioni di codice offuscato che replicano la presenza del worm. La propagazione sfrutta operazioni quotidiane, in modo che il codice infetto sia copiato, validato o incluso in artifact condivisi. Parallelamente GlassWorm stabilisce canali di comando e controllo per ricevere aggiornamenti e istruzioni, complicando il tracciamento.

Il pericolo della sua infezione risiede nelle copie già propagate. Infatti, il codice infetto può viaggiare insieme ai repository, agli snippet e ai pacchetti, arrivando così in ambienti diversi. Rimuovere l’estensione compromessa non è nemmeno una misura mitigativa, poiché le copie esistenti di GlassWorm non vengono cancellate in nessun modo.

La propagazione di GlassWorm assieme al codice di sviluppo trasforma la supply chain in un canale di infezione particolarmente pericoloso. Questo perché molti artifact sono inclusi senza una revisione approfondita e le pratiche standard di sviluppo accelerano la sua diffusione. Perciò una singola estensione malevola può raggiungere in breve tempo numerosi progetti e ambienti aziendali.

Come difendersi da GlassWorm

Per difendersi da un worm auto-propagativo del genere occorre intervenire su tutto il ciclo di sviluppo, dalla workstation del programmatore alle pipeline di distribuzione. Di seguito sono riportate alcune misure contenitive per limitare l’insorgenza di una minaccia simile.

• Limitare e validare le estensioni installabili.
  Utilizzare solo quelle provenienti dal marketplace ufficiale o da fonti interne firmate; bloccare l’installazione manuale e applicare policy di approvazione da parte dell’IT o del team DevSecOps. Garantire l’integrità del codice generato e permettere la verifica automatica di ogni componente prima della distribuzione.
• Firmare digitalmente gli artefatti di build e le estensioni aziendali.
  Garantire l’integrità del codice generato e permettere la verifica automatica di ogni componente prima della distribuzione.
• Implementare scansioni SCA e monitoraggio dei repository.
  Rilevare codice anomalo, dipendenze sconosciute o file modificati fuori dai commit autorizzati; impostare alert in caso di script offuscato o modifiche automatiche.
• Eseguire audit e revisioni periodiche dei file di configurzione VS Code.
  Confrontare le configurazioni attuali con baseline note per rilevare inserimenti non autorizzati o file nascosti.
• Isolare l’ambiente di sviluppo dal resto della rete.
  Limitare le connessioni in uscita dell’IDE e dei suoi plugin, evitando che eventuali moduli malevoli comunichino con infrastrutture di comando esterne.
• Integrare controlli di sicurezza nella pipeline CI/CD.
  Scansioni automatiche degli artefatti prima del rilascio e rigenerazione da sorgenti verificati; blocco del deploy se rilevata presenza di codice offuscato o script non firmati.

In conclusione

La scoperta di GlassWorm dimostra che gli attacchi possono partire dagli stessi strumenti che usiamo per costruire il software. Quando l’ambiente di sviluppo diventa vettore, bisogna ripensare i controlli su estensioni, artifact e processi quotidiani degli sviluppatori. Il rischio derivante ha seri impatti su progetti e pipeline.

Ecco perché si chiede di restringere le fonti delle estensioni, firmare gli artifact, ispezionare ogni modifica ai file di progetto e bloccare eventuali distribuzioni non verificate. Isolare l’IDE, integrare controlli nelle pipeline e predisporre un piano di bonifica della supply chain riducono enormemente la possibilità che una singola estensione infetta generi una catena di contaminazione. Senza queste misure, la fiducia negli strumenti rimane un punto debole sfruttabile.