La campagna malware GlassWorm sta alimentando un attacco di supply chain mirato a sviluppatori e aziende che usano GitHub e Python. Gli aggressori sfruttano token GitHub rubati per inserire codice dannoso in centinaia di repository Python, colpendo progetti molto diffusi come applicazioni Django, codice di ricerca per machine learning, dashboard Streamlit e anche pacchetti destinati a PyPI. Il rischio principale è che chiunque esegua pip install da un repository compromesso o cloni ed esegua il progetto possa attivare il malware senza accorgersene.

Il vettore è legato alla compromissione degli account degli sviluppatori. Secondo le analisi, le prime iniezioni risalgono all’8 marzo 2026. La tecnica è particolarmente insidiosa perché non si limita ad aggiungere un commit evidente: gli attaccanti prendono gli ultimi commit legittimi del branch di default, li riorganizzano con un rebase e poi eseguono un force push che riscrive la storia Git. In questo modo mantengono intatti messaggio, autore e data del commit originale, riducendo la visibilità delle modifiche malevole nell’interfaccia di GitHub e rendendo più difficile accorgersi della compromissione tramite i normali controlli basati sulla cronologia.

Il codice malevolo viene tipicamente aggiunto in fondo a file comuni nei progetti Python come setup.py, main.py e app.py, spesso in forma offuscata e con payload codificato in Base64. Una volta eseguito, il malware effettua controlli per evitare l’esecuzione su sistemi con impostazioni locali russe, mentre sugli altri sistemi procede a recuperare istruzioni e ulteriori componenti.

Un elemento distintivo di questa ondata è l’uso di infrastruttura legata a wallet Solana. Il malware interroga un campo memo associato a un indirizzo di wallet per estrarre un URL aggiornato del payload, che può cambiare frequentemente. Da lì scarica ulteriori carichi, inclusi componenti in JavaScript cifrato progettati per il furto di criptovalute e dati. Questo approccio rende più flessibile la catena di infezione e complica i blocchi statici basati su indicatori fissi.

Sono emersi anche casi in cui la stessa campagna avrebbe colpito pacchetti npm, con versioni malevole pubblicate e meccanismi di esecuzione in memoria e lock temporali per limitare la riesecuzione, segnalando una strategia ampia e multi-ecosistema.