Nel mondo dello sviluppo software esiste un presupposto implicito: se il codice appare pulito a chi lo esamina, allora può essere considerato affidabile. La campagna GlassWorm mette in crisi proprio questa idea. Secondo le analisi pubblicate a marzo 2026 da più società di sicurezza, gli attaccanti hanno nascosto payload malevoli dentro caratteri Unicode invisibili, inseriti in repository e pacchetti open source ospitati su GitHub, npm, VS Code/Open VSX e altri ambienti usati ogni giorno da milioni di sviluppatori.
Il punto più delicato non riguarda solo la presenza del malware, ma il metodo scelto per distribuirlo. A prima vista, le modifiche al codice sembrano banali correzioni o piccoli aggiornamenti coerenti con il progetto. In realtà, dentro stringhe che appaiono vuote, o in sezioni che sembrano innocue, vengono collocati caratteri che l’occhio umano non percepisce. Quando il codice viene eseguito, questi caratteri vengono decodificati e trasformati in istruzioni attive, fino ad arrivare in molti casi all’esecuzione di altro codice scaricato dall’esterno. Aikido ha descritto questa tecnica come una nuova ondata di attacchi Unicode invisibili collegata a GlassWorm.
Il meccanismo ricorda da vicino il problema noto come Trojan Source, reso pubblico nel 2021 dai ricercatori dell’Università di Cambridge. In quel caso, l’allarme riguardava il modo in cui Unicode poteva alterare la comprensione del codice da parte di chi lo leggeva. GlassWorm porta quel concetto a un livello ulteriore: non punta solo a confondere la revisione del codice, ma usa l’invisibilità dei caratteri per nascondere direttamente il payload malevolo all’interno delle dipendenze software.
Il problema diventa ancora più serio per la struttura stessa del software moderno. Oggi quasi nessuna applicazione nasce da zero: ogni progetto incorpora librerie esterne, che a loro volta richiamano altre librerie. Basta quindi compromettere un componente apparentemente secondario per aprire la strada a una catena di infezioni molto più ampia. È il motivo per cui gli attacchi alla software supply chain preoccupano da anni gli esperti: l’anello debole non è per forza il software finale, ma una dipendenza a monte che nessuno controlla fino in fondo.
La campagna osservata a marzo 2026 si è distinta per scala e continuità. Aikido ha riferito di almeno 151 repository GitHub colpiti tra il 3 e il 9 marzo, con una cifra che potrebbe risultare persino sottostimata perché parte dei repository compromessi è stata rimossa nel frattempo. Altri report hanno esteso il quadro, parlando di una presenza di GlassWorm in centinaia di repository, pacchetti ed estensioni distribuiti su più piattaforme.
Non si tratta di un’operazione dimostrativa. Le società che hanno analizzato la minaccia spiegano che il codice nascosto viene usato per scaricare moduli secondari capaci di sottrarre token, credenziali di sviluppatori, segreti applicativi e, in diversi casi, dati collegati ai wallet di criptovalute. Un report di Mondoo parla apertamente di esecuzione arbitraria di codice tramite payload invisibili, mentre StepSecurity e SecurityWeek hanno collegato la campagna anche al furto di token GitHub e a successive compromissioni di repository Python.
Uno degli aspetti più insidiosi emersi nelle analisi riguarda proprio la capacità degli attaccanti di muoversi dentro flussi di lavoro che, sulla carta, dovrebbero offrire garanzie. Secondo StepSecurity, in una fase successiva dell’operazione gli autori hanno sfruttato token GitHub rubati per inserire codice malevolo in repository Python e riscrivere la cronologia con force-push, senza lasciare i segnali tipici di una pull request sospetta. In pratica, non viene messa sotto pressione solo la fiducia nel codice open source, ma anche quella negli strumenti di collaborazione che regolano lo sviluppo quotidiano.
Il caso GlassWorm mostra così una fragilità strutturale. Per anni la sicurezza del software open source si è basata anche sulla possibilità che molti occhi vedessero i problemi. Qui, però, gli occhi non bastano, perché il contenuto malevolo può risultare letteralmente invisibile. La lezione è netta: la revisione umana resta importante, ma non è sufficiente senza strumenti capaci di rilevare caratteri Unicode anomali, differenze sospette nei file e comportamenti anomali nelle dipendenze. È anche per questo che diversi ricercatori invitano a rafforzare i controlli automatici sulla supply chain e a non scaricare l’intera responsabilità sui manutentori open source, spesso già sotto pressione e con risorse limitate.
Per aziende e team di sviluppo il messaggio è chiaro: non basta più verificare se un pacchetto arriva da una fonte nota o se il diff sembra innocuo. Serve una difesa più profonda, capace di analizzare il testo del codice a livello Unicode, di controllare la provenienza reale delle dipendenze e di bloccare esecuzioni dinamiche sospette. GlassWorm non introduce soltanto una nuova famiglia di attacchi. Rende evidente che una parte della sicurezza software moderna si fonda ancora su una fiducia visiva che, oggi, gli attaccanti hanno imparato a manipolare.
.
