GlassWorm nutzt Entwickler-Ökosysteme für neue Supply-Chain-Angriffe : Manipulierte Erweiterungen und versteckter Code gefährden Entwickler und Open-Source-Projekte

Softwarelieferketten sind längst zu einem zentralen Angriffsziel für Cyberkriminelle geworden. Aktuelle Analysen mehrerer Sicherheitsunternehmen zeigen nun eine deutliche Eskalation der GlassWorm-Kampagne. Die Angreifer nutzen dabei Entwicklerplattformen, Paketmanager und Erweiterungsregister, um Schadsoftware über scheinbar legitime Tools zu verbreiten.

Erweiterungen im Open VSX Registry als Angriffspunkt

Im Zentrum der neuen Angriffswelle steht das Erweiterungsregister Open VSX. Sicherheitsforscher entdeckten dort mindestens 72 weitere bösartige Erweiterungen, die speziell auf Entwickler abzielen. Diese Erweiterungen imitieren verbreitete Entwicklerwerkzeuge wie Code-Linter, Formatierungsprogramme, Code-Runner oder Hilfsmittel für KI-gestützte Programmierassistenten.

Zu den identifizierten Erweiterungen gehören unter anderem:

• angular-studio.ng-angular-extension
• crotoapp.vscode-xml-extension
• gvotcha.claude-code-extension
• mswincx.antigravity-cockpit
• tamokill12.foundry-pdf-extension
• turbobase.sql-turbo-tool
• vce-brendan-studio-eich.js-debuger-vscode

„Statt jede schädliche Erweiterung direkt mit einem Loader auszustatten, nutzen die Angreifer nun extensionPack und extensionDependencies, um zunächst harmlos wirkende Erweiterungen später zu Verteilsystemen für Malware umzubauen“, erklärt Socket in einem Bericht. „Ein Paket, das anfangs unauffällig erscheint, kann so nach einem Update plötzlich eine zusätzliche Erweiterung nachladen, die mit GlassWorm verbunden ist – lang genug verzögert, damit Vertrauen in das Paket bereits aufgebaut ist.“

Das Betreiberteam von Open VSX hat die betroffenen Erweiterungen inzwischen aus dem Register entfernt. Dennoch zeigt der Vorfall, wie leicht sich vertrauenswürdige Entwicklerumgebungen für Angriffe missbrauchen lassen.

Bekannte Kampagne mit neuen Fähigkeiten

GlassWorm ist eine fortlaufende Malware-Kampagne. Dabei schleusen Angreifer immer wieder bösartige Erweiterungen in das Microsoft Visual Studio Marketplace und das Erweiterungsregister Open VSX ein. Ziel dieser Erweiterungen ist es, vertrauliche Daten zu stehlen, Kryptowährungs-Wallets zu plündern und kompromittierte Rechner als Proxy-Systeme für weitere kriminelle Aktivitäten zu missbrauchen.

Erstmals wurde die Kampagne im Oktober 2025 von dem Sicherheitsunternehmen Koi Security entdeckt. Ähnliche Angriffsmethoden tauchten allerdings schon früher auf: Bereits im März 2025 wurden npm-Pakete gefunden, die dieselben Techniken nutzten – insbesondere unsichtbare Unicode-Zeichen, mit denen sich schädlicher Code im Quelltext verstecken lässt.

Auch die aktuelle Variante der Kampagne weist typische Merkmale von GlassWorm auf. So prüfen die Schadprogramme zunächst, ob ein System ein russisches Gebietsschema verwendet. In diesem Fall wird eine Infektion vermieden. Außerdem nutzen die Angreifer Transaktionen der Kryptowährung Solana, um darüber die Adresse ihres Command-and-Control-Servers abzurufen. Diese Technik erhöht die Widerstandsfähigkeit der Infrastruktur, weil sich die Steuerungsserver dadurch flexibler wechseln lassen.

Neue Angriffsstrategie über Erweiterungsabhängigkeiten

Die neu entdeckten Erweiterungen gehen jedoch noch weiter. Sie verwenden stärkere Verschleierungstechniken und wechseln regelmäßig die eingesetzten Solana-Wallets, um eine Entdeckung zu erschweren. Zudem missbrauchen sie gezielt Abhängigkeiten zwischen Erweiterungen, um Schadsoftware zu verbreiten. Ein ähnliches Vorgehen ist bereits aus Angriffen auf npm-Pakete bekannt, bei denen manipulierte Abhängigkeiten eingesetzt werden.

Technisch funktioniert das über die Datei package.json. Dort können Erweiterungen als extensionPack oder extensionDependencies definiert werden. Der Editor installiert automatisch alle Erweiterungen, die dort aufgeführt sind.

Die Angreifer nutzen diesen Mechanismus aus, indem eine scheinbar harmlose Erweiterung als Installationsprogramm für eine zweite, tatsächlich bösartige Erweiterung dient. Dadurch entstehen neue Angriffsmöglichkeiten auf die Softwarelieferkette. Ein Angreifer kann zunächst eine völlig unauffällige Erweiterung für Visual Studio Code veröffentlichen und damit die Prüfmechanismen im Marketplace passieren. Erst später wird die Erweiterung aktualisiert und enthält dann eine Abhängigkeit zu einer GlassWorm-Erweiterung.

„Eine Erweiterung, die bei ihrer ersten Veröffentlichung harmlos wirkte und keine Abhängigkeiten hatte, kann später zu einem Verteiler für GlassWorm werden – ohne dass sich ihr sichtbarer Zweck verändert“, erklärt das Sicherheitsunternehmen Socket.

Unsichtbarer Schadcode in Open-Source-Repositories

Parallel zu den Erweiterungsangriffen warnt Aikido vor einer weiteren Technik: Schadcode wird über unsichtbare Unicode-Zeichen in Quelltextdateien eingeschleust.

Diese Zeichen sind in Code-Editoren und Terminalfenstern nicht sichtbar, können aber beim Interpretieren des Codes eine zusätzliche Schadfunktion aktivieren. Die Technik wurde zwischen dem 3. und 9. März 2026 in mindestens 151 Repositories auf GitHub entdeckt.

Auch zwei npm-Pakete nutzten dieselbe Methode:

• @aifabrix/miso-client
• @iflow-mcp/watercrawl-watercrawl-mcp

Der versteckte Code lädt anschließend eine zweite Malware-Stufe nach, die Zugangsdaten, Tokens und andere Geheimnisse exfiltriert. „Die schädlichen Änderungen erscheinen nicht als offensichtlich verdächtige Commits. Die umgebenden Änderungen wirken realistisch – Dokumentationsupdates, Versionsanpassungen oder kleine Refactorings“, erklärt Sicherheitsanalyst Ilyas Makari die Täuschungsstrategie.

Diese hohe Anpassungsfähigkeit deutet darauf hin, dass Angreifer möglicherweise große Sprachmodelle einsetzen, um glaubwürdige Codeänderungen zu generieren.

Manipulierte npm-Pakete und dynamische Abhängigkeiten

Eine weitere Untersuchung identifizierte 88 bösartige npm-Pakete, die zwischen November 2025 und Februar 2026 veröffentlicht wurden. Diese Pakete konnten sensible Daten von kompromittierten Systemen sammeln, darunter:

• Umgebungsvariablen
• CI/CD-Tokens
• Systemmetadaten

Auffällig war dabei die Nutzung sogenannter Remote Dynamic Dependencies (RDD). Dabei verweist eine Abhängigkeit in der Datei package.json auf eine externe HTTP-Adresse statt auf ein Paket im npm-Register.

Diese Technik erlaubt es Angreifern, den Schadcode jederzeit zu verändern, ohne eine neue Paketversion veröffentlichen zu müssen.

Experiment oder versteckte Angriffskampagne?

Die npm-Pakete wurden zunächst der Kampagne PhantomRaven zugerechnet. Später erklärte ein Sicherheitsforscher jedoch, dass es sich dabei um ein legitimes Experiment gehandelt habe. Diese Darstellung stößt jedoch auf erhebliche Zweifel. Sicherheitsexperten verweisen auf mehrere Auffälligkeiten:

• Die Pakete sammeln deutlich mehr Informationen als für ein Experiment notwendig wäre.
• Nutzer wurden nicht transparent darüber informiert, welche Daten erfasst werden.
• Die Veröffentlichung erfolgte über zahlreiche wechselnde Konten und E-Mail-Adressen.

Am 12. März 2026 nahm der Betreiber der Pakete weitere Änderungen vor. Der zuvor enthaltene Code zur Datensammlung, der über einige der in den vergangenen drei Monaten veröffentlichten npm-Pakete verbreitet wurde, wurde durch eine einfache „Hello, world!“-Meldung ersetzt.

„Dass der Code zur umfangreichen Datensammlung entfernt wurde, ist zwar positiv, zeigt aber zugleich die Risiken sogenannter URL-Abhängigkeiten“, erklärte Endor Labs. „Wenn Pakete Code von Servern außerhalb des npm-Registers laden, behalten die Autoren jederzeit die Kontrolle darüber – ohne eine neue Paketversion veröffentlichen zu müssen. Sie müssen nur eine einzige Datei auf ihrem Server ändern oder entfernen, um das Verhalten aller abhängigen Pakete gleichzeitig und unbemerkt zu verändern.“