Die Kampagne setzte sich über mehrere Wellen fort und weitete sich auf den offiziellen Visual-Studio-Code-Marktplatz von Microsoft sowie die OpenVSX-Registry aus, die von nicht unterstützten Entwicklungsumgebungen genutzt wird. Diese Ausweitung entdeckte John Tuckner, Forscher bei Secure Annex. Im Verlauf der Angriffe gerieten auch macOS-Systeme ins Visier, für die trojanisierte Clients für Trezor und Ledger eingeschleust wurden; später richteten sich die Angriffe über kompromittierte OpenVSX-Erweiterungen gegen Entwickler.
Der Ablauf folgt einem festen Muster: Die anfängliche Kompromittierung erfolgt auf GitHub, wo übernommene Konten genutzt werden, um per Force-Push manipulierte Commits einzuspielen. Anschließend werden auf npm und im VSCode/OpenVSX-Ökosystem schädliche Pakete und Erweiterungen veröffentlicht, deren Code durch unsichtbare Unicode-Zeichen verschleiert ist, um einer Erkennung zu entgehen.
Auf allen Plattformen fragt die Schadsoftware alle fünf Sekunden die Solana-Blockchain nach neuen Anweisungen ab. Laut Step Security gab es zwischen dem 27. November 2025 und dem 13. März 2026 50 neue Transaktionen, die überwiegend dazu dienten, die URL der Schadroutine zu aktualisieren. Die Anweisungen waren als Memos in den Transaktionen hinterlegt und führten zum Herunterladen der Node.js-Laufzeitumgebung sowie zur Ausführung eines JavaScript-basierten Informationsdiebs. Dieser zielt auf Wallet-Daten, Zugangsdaten und Access-Tokens, SSH-Schlüssel sowie Daten aus der Entwicklungsumgebung.
Die Analyse von Code-Kommentaren deutet laut den Forschern auf russischsprachige Bedrohungsakteure hin; zudem bricht die Schadsoftware die Ausführung ab, wenn auf dem System die russische Spracheinstellung gefunden wird. Für eine belastbare Zuordnung reichen diese Hinweise jedoch nicht aus.
Step Security rät Entwicklern, die Python-Pakete direkt von GitHub installieren oder geklonte Repositories ausführen, ihren Code nach der Markervariable “lzcdrtfxyqiplpd” zu durchsuchen – einem Indikator für die GlassWorm-Schadsoftware. Außerdem sollten Systeme auf die Datei ~/init.json geprüft werden, die der Persistenz dient, sowie auf unerwartete Node.js-Installationen im Benutzerverzeichnis (etwa ~/node-v22*).
Weitere Hinweise liefern verdächtige i.js-Dateien in kürzlich geklonten Projekten sowie Auffälligkeiten in der Git-Commit-Historie – etwa Commits, deren Committer-Datum deutlich neuer ist als das ursprüngliche Autoren-Datum.