Un account sviluppatore compromesso su Open VSX Registry ha permesso la distribuzione di estensioni VS Code malevole che installano Glassworm Loader, un malware supply chain attivo almeno da ottobre 2025. L’incidente, avvenuto il 30 gennaio 2026, evidenzia un’escalation nelle tecniche di abuso degli ecosistemi open-source e impone verifiche immediate su credenziali, token di pubblicazione e pipeline CI/CD. L’attacco ha sfruttato un account storico e apparentemente affidabile, oorzc, per pubblicare release malevole di estensioni molto scaricate. Il team sicurezza di Open VSX Registry, con il supporto della Eclipse Foundation, ha revocato i token, rimosso le versioni infette e bloccato il publisher, ma il caso dimostra quanto la fiducia implicita nei registry sia oggi un vettore primario di compromissione.
Compromissione dell’account oorzc e risposta di Open VSX
Il 30 gennaio 2026 i threat actor hanno pubblicato aggiornamenti malevoli sotto il namespace oorzc, valutati come legati a token di pubblicazione leaked o accesso non autorizzato alle credenziali. Le release sono state rapidamente individuate: i token del publisher sono stati disabilitati, le versioni ritirate e oorzc.ssh-tools è stata classificata come malware. La risposta è stata rapida, ma il blast radius potenziale resta elevato perché l’account era attivo da anni e godeva di ampia legittimità.
Estensioni VS Code coinvolte e impatto
Quattro estensioni hanno veicolato il loader, per oltre 22.000 download cumulativi prima della rimozione. Le versioni malevole includevano codice offuscato all’interno dei pacchetti .vsix, attivato all’avvio dell’estensione. L’uso di utility per sviluppatori — FTP/SFTP/SSH Sync Tool, I18n Tools, vscode mindmap, scss to css — ha aumentato la probabilità di installazione in ambienti sensibili.
Glassworm Loader: architettura e catena di infezione
Glassworm Loader è progettato come loader staged, con decrypt a runtime per ridurre indicatori statici.
Lo stage zero usa AES-256-CBC per decrittare stringhe esadecimali ed eseguirle via eval.
Lo stage uno applica controlli ambientali (geofencing, lingua e time zone) ed evita sistemi russi; se l’host è idoneo, recupera i puntatori C2 da memo su blockchain Solana, usando un dead drop per rendere dinamica l’infrastruttura.
Lo stage due è macOS-specific: un payload Node.js che ruba dati e imposta persistenza tramite LaunchAgent (plist in ~/Library/LaunchAgents), eseguendosi al login.
Obiettivi e dati sottratti
Il focus non è la replica automatica ma il furto di credenziali per estendere la portata dell’attacco. Il malware raccoglie cookie e credenziali browser (Chromium, Firefox, Safari), wallet crypto (inclusi plugin e client desktop), Keychain macOS, Apple Notes, configurazioni VPN, e soprattutto segreti da sviluppatore: chiavi SSH, token npm, artefatti GitHub, credenziali AWS. I dati vengono compressi ed esfiltrati verso endpoint remoti. L’attenzione su macOS riflette il target primario: workstation di sviluppatori.
Perché questo attacco è diverso
La campagna dimostra una maturità superiore: account takeover invece di pacchetti nuovi sospetti, offuscamento runtime, C2 via blockchain per ridurre IOC stabili, e selezione mirata degli host. È una supply chain attack che bypassa molte difese tradizionali e richiede detection comportamentale e risposta rapida.
Cosa devono fare subito utenti e team
Gli utenti devono rimuovere le estensioni coinvolte, verificare persistenza su macOS (LaunchAgents), e controllare directory temporanee e artefatti locali. Gli sviluppatori devono ruotare immediatamente token GitHub, npm, chiavi SSH, credenziali cloud, auditare commit e workflow CI, e validare i job di release. È fondamentale ridurre l’uso di token long-lived, applicare 2FA ovunque e separare i permessi di pubblicazione.
Implicazioni per l’ecosistema open-source
Il caso oorzc segnala un cambio di passo: i threat actor colpiscono account consolidati per massimizzare fiducia e diffusione. I registry devono rafforzare verifiche sui publisher, scansioni comportamentali e revoche rapide. Per i team, la sicurezza della supply chain non è più opzionale: servono policy di rotazione, monitoraggio continuo e gating automatico delle dipendenze.
Domande frequenti su Glassworm Loader e l’incidente Open VSX
Chi è stato colpito dall’attacco su Open VSX?
Utenti che hanno installato versioni specifiche di quattro estensioni pubblicate dall’account oorzc il 30 gennaio 2026. Le release sono state rimosse, ma è necessaria la verifica locale.
Windows e Linux sono a rischio?
La fase payload osservata è macOS-specifica. Tuttavia, la compromissione iniziale avviene a livello di estensione e richiede comunque audit e rotazione credenziali su tutte le piattaforme.
Perché usare Solana come C2?
I memo on-chain permettono dead drop dinamici, riducendo IOC statici e rendendo più difficile il blocco preventivo.
Qual è la mitigazione più efficace per i team?
Rotazione immediata dei segreti, 2FA, token a breve durata, audit dei workflow di pubblicazione, e monitoraggio comportamentale delle dipendenze installate.
Iscriviti alla Newsletter
Non perdere le analisi settimanali: Entra nella Matrice Digitale.
Matrice Digitale partecipa al Programma Affiliazione Amazon EU...
