Glassworm kompromittiert 151 GitHub-Repositories in einer Woche Wie Glassworm vier Ökosysteme gleichzeitig unterwanderte

Die Glassworm-Kampagne markiert einen Paradigmenwechsel bei Supply-Chain-Angriffen. Innerhalb einer Woche kompromittierten die Angreifer 151 GitHub-Repositories und verteilten Schadcode über npm, VS Code Market­place und Open VSX. Bereits der npm-Wurm Shai-Hulud hatte Ende 2025 erwarten lassen, dass solche Angriffe kein Einzelfall bleiben.

Ende Dezember vergangenen Jahres haben wir den npm-Wurm Shai-Hulud analysiert und dabei eine unbequeme These formuliert: Was dort an Techniken sichtbar wurde, war kein isolierter Vorfall, sondern ein Prototyp. Shai-Hulud hatte demonstriert, wie sich Schadcode über die Identität einzelner Entwickler und das implizite Vertrauen moderner CI/CD-Pipelines selbstständig verbreiten kann. Wir warnten damals, dass die Branche einen Fehler beging, indem sie den Vorfall als Einzelfall behandelte.

Keine drei Monate später nun die Glassworm-Kampagne den Beweis, dass diese Einschätzung nicht übertrieben war – und dass sich die Bedrohung schneller weiterentwickelt, als die meisten Sicherheitsteams antizipiert haben.

GitHub, npm und VS Code betroffen

Neue GlassWorm-Angriffswelle trifft Hunderte von Repositories und Pakete

Unsichtbarer Schadcode, sichtbare Konsequenzen

Zwischen dem 3. und 9. März kompromittierte der Glassworm mindestens 151 GitHub-Repositories und verteilte manipulierte Pakete über npm, den VS Code Marketplace und die Open VSX Registry – vier unterschiedliche Ökosysteme in einer einzigen, koordinierten Kampagne. Die technische Grundlage ist dabei ebenso elegant wie beunruhigend. Die Angreifer nutzten unsichtbare Unicode-Zeichen aus dem Private Use Area, um vollständige Schadcode-Payloads in Zeichenketten zu kodieren, die in jedem Editor, jedem Terminal und jedem Code-Review-Interface als leerer String erscheinen. Erst zur Laufzeit dekodiert ein kleiner Loader die versteckten Bytes und übergibt sie an eval().

Besonders aufschlussreich ist die Vorgehensweise im Open-VSX-Ökosystem. Statt den kompletten Schadcode in jede Extension einzubetten, setzten die Angreifer auf ein transitives Lademuster: Eine erste, vergleichsweise harmlos wirkende Extension fungierte als stiller Installer für eine zweite, stärker verschleierte Variante. Die gefährliche Payload entfaltet sich erst nach der Installation, wenn die erste Extension die zweite nachlädt. Damit hebelt Glassworm das Prüfmodell aus, auf das die meisten Extension-Marktplätze setzen – eine einmalige Begutachtung zum Zeitpunkt der Veröffentlichung.

Unter den Zielen befanden sich Repositories von Wasmer, Reworm und der Organisation hinter OpenCode und SST – Projekte mit realer Verbreitung im Downstream. Das ist kein Typosquatting, bei dem jemand auf Tippfehler hofft. Das ist gezielte Infiltration vertrauenswürdiger Codebasen.

Update: Neue Variante des Shai-Hulud Worm

Supply-Chain-Angriff trifft über 1.000 npm-Pakete

Die Prognosen, die eingetreten sind

In unserer Shai-Hulud-Analyse hatten wir mehrere konkrete Entwicklungspfade für Supply-Chain-Angriffe skizziert. Glassworm bestätigt drei davon in einer einzigen Kampagne.

Erstens die ökosystem­übergreifende Koordination. Wir hatten vor dem „Polyglot Worm" gewarnt – einem Angriff, der Sicherheitssilos nahtlos durchquert. Glassworm operierte gleichzeitig in GitHub-Repositories, npm-Paketen, VS-Code-Erweiterungen und Open VSX. Ein JavaScript-Sicherheitsteam, das npm überwacht, hätte die kompromittierten GitHub-Repositories nicht bemerkt. Ein Team, das den VS Code Marketplace auditiert, hätte keinen Anlass gehabt, Open VSX zu prüfen. Der Angriff ist darauf ausgelegt, die Organisationsstruktur des Verteidigers auszuhebeln.

Zweitens die KI-gestützte Tarnung. Wir hatten prognostiziert, dass KI für Angreifer zum Skalierungsinstrument wird – vom sogenannten Hallucination Hijacking, bei dem Paketnamen registriert werden, die KI-Tools fälschlicherweise als existent vorhersagen, bis hin zur Automatisierung von Tarnmaßnahmen. Glassworm löst den zweiten Teil dieser Prognose ein. Die begleitenden Commits – Dokumentationsanpassungen, Versionsinkremente, kleinere Refactorings – sind stilistisch konsistent über die jeweiligen Zielprojekte hinweg. Bei mehr als 151 kompromittierten Repositories ist die manuelle Erstellung maßgeschneiderter Tarn-Commits schlicht nicht realistisch. Die Angreifer setzen mit hoher Wahrscheinlichkeit Large Language Models ein, um kontextuell passende Änderungen zu generieren, die sich nahtlos in die Projekthistorie einfügen.

Drittens die unsichtbare Persistenz. Wir hatten beschrieben, wie künftige Angriffe nicht mehr nur den Quellcode selbst, sondern die Tooling- und Identitätsschichten drumherum ins Visier nehmen würden. Glassworm modifiziert Code nicht in einer Form, die ein menschlicher Reviewer erkennen könnte. Der Schadcode verbirgt sich in der Encoding-Schicht, unterhalb der Abstraktion, die jedes moderne Entwicklungswerkzeug dem Entwickler präsentiert. Visuelles Code-Review greift hier nicht. Standardmäßiges Linting greift nicht. Die Angriffsfläche ist die Lücke zwischen dem, was die Maschine ausführt, und dem, was der Mensch wahrnimmt.

Supply-Chain-Security im Fokus

Lehren aus dem npm-Supply-Chain-Angriff

Warum herkömmliche Abwehrstrategien nicht ausreichen

Glassworm stellt eine Reihe von Grundannahmen infrage, auf die sich viele Sicherheitsorganisationen nach wie vor stützen. Wer darauf vertraut, dass Entwickler verdächtigen Code im Pull Request erkennen, muss zur Kenntnis nehmen, dass der Schadcode zwar im Diff vorhanden ist, aber von keinem menschlichen Auge wahrgenommen werden kann. Wer sein Vulnerability Management auf bekannte CVEs und veröffentlichte Advisories beschränkt, operiert mit einer Reaktionszeit, die Angreifer gezielt einkalkulieren. Und wer npm, GitHub, IDE-Erweiterungen und Open VSX als getrennte Vertrauensdomänen behandelt, hat exakt die Art von siloisierter Verteidigung aufgebaut, die Glassworm systematisch umgeht.

Die unbequeme Konsequenz für Sicherheitsverantwortliche ist, den gesamten Entwicklungszyklus als zusammenhängende Angriffsfläche zu begreifen – vom lokalen Entwicklerarbeitsplatz über die Build-Systeme bis zu den Paketregistries. Das erfordert Sichtbarkeit, die über das hinausgeht, was die meisten Organisationen heute abbilden. Werkzeuge, die unsichtbare Unicode-Injection-Muster erkennen können – nicht nur in neuen Abhängigkeiten, sondern auch in bestehenden, die möglicherweise nachträglich kompromittiert wurden. Laufende Überwachung von Dependencies auf ungewöhnliche Aktivitäten wie plötzliche Maintainer-Wechsel, atypische Commit-Muster oder unerwartete Versionsupdates. Und eine Incident-Response-Fähigkeit, die schnell genug ist, um kompromittierte Komponenten über alle Umgebungen hinweg zu identifizieren und betroffene Zugangsdaten zu rotieren, bevor der Schaden sich ausbreitet.

Wer diese Sichtbarkeit und Reaktionsfähigkeit nicht aus eigenen Ressourcen aufbauen kann (oder will), sollte sich ehrlich fragen, ob spezialisierte Partner im Vulnerability Management der effizientere Weg sind, diese Lücken zu schließen.

gesponsert Security-Insider Deep Dive mit Mondoo

Detection und Remediation von Supply-Chain-Angriffen

Eine neue operative Realität

Glassworm ist kein singuläres Ereignis, das sich mit einem Advisory und ein paar rotierten Credentials abhaken lässt. Die Kampagne markiert den Übergang von einem Bedrohungs­mo­dell, das auf einzelne schadhafte Pakete fokussiert war, hin zu einer Realität, in der sich Würmer automatisiert, unsichtbar und ökosystemübergreifend verbreiten. Wer seine Sicher­heits­ar­chi­tek­tur nicht darauf einstellt, verteidigt einen Status Quo, den es so nicht mehr gibt.

Wir haben das Advisory MONDOO-ADV-2026-668sg zu den bislang bekannten betroffenen npm-Paketen veröffentlicht und verfolgen die Kampagne weiter. Aber das Minimum reicht nicht. Denn was Glassworm zeigt, ist kein vorübergehendes Phänomen, sondern ein Paradigmenwechsel in der Art, wie Software-Supply-Chains angegriffen werden.

Über den Autor: Patrick Münch ist Mitgründer und CISO bei Mondoo.

Analyse von Sysdig

So werden Self-hosted GitHub Actions Runner als Backdoors missbraucht

(ID:50813884)