Dreimal innerhalb von acht Monaten funktionierte dasselbe npm-Worm-Muster. Unterschiedliche Angreifer, unterschiedliche Pakete, aber dieselbe Funktionsweise und dasselbe Zeitfenster zwischen Veröffentlichung und Entdeckung – all das machte es möglich. Falls Sie sich fragen, was ein npm-Worm eigentlich ist und warum sich dieses Muster immer wiederholt, anstatt behoben zu werden: Hier ist die ehrliche Antwort – zu den Vorfällen, der Funktionsweise und der einen Sicherheitslücke, die selbst ein solides Schutzsystem noch aufweist.
Was ist ein npm-Wurm?
Ein npm-Wurm ist ein Schadcode, der im npm-Repository veröffentlicht wird und sich nach dem Ausführen automatisch auf andere Pakete ausbreitet. Dies geschieht typischerweise durch den Diebstahl der Zugangsdaten eines Paketbetreuers und dessen Verwendung, um denselben Schadcode in jedes von ihm verwaltete Paket einzuschleusen. Es handelt sich um einen „Wurm“ im klassischen Sinne: Er wartet nicht darauf, dass ihn jemand absichtlich installiert, sondern verbreitet sich selbstständig, Paket für Paket, Benutzerkonto für Benutzerkonto, in Echtzeit.
Diese Selbstverbreitung unterscheidet einen npm-Wurm-Vorfall von einem gewöhnlichen Schadprogramm. Ein einzelnes schädliches Paket ist wie die Nadel im Heuhaufen. Ein npm-Wurm macht jeden kompromittierten Maintainer zu einem neuen Verbreitungspunkt, und der Heuhaufen beginnt, seine eigenen Nadeln zu erzeugen.
Die bisher größten npm-Wurm-Vorfälle
Im vergangenen Jahr wurde das npm-Wurmmuster drei Mal in der Praxis getestet, wobei jeder Testlauf effizienter war als der vorherige:
- Shai-Hulud (September 2025). Der erste dokumentierte, sich selbst verbreitende npm-Wurm. Er kompromittierte die Zugangsdaten von Paketbetreuern und nutzte diese anschließend, um bösartige Versionen aller Pakete unter deren Kontrolle zu veröffentlichen. Dadurch wurden die Entwickler selbst zum Verbreitungsmechanismus für die nächste Phase des Wurms.
- axios (März 2026). Staatlich gesteuerte Schadsoftware, versteckt in einem Paket, wird etwa 100 Millionen Mal pro Woche heruntergeladen. Kein Wurm im engeren Sinne, aber ein Beweis dafür, dass dasselbe Vertrauensmodell des npm-Ökosystems, das Shai-Hulud ausnutzte, auch Schadsoftware in wirklich großem Umfang transportieren kann.
- SAP npm (April 2026). Damals wurde es als eine Art Mini-Shai-Hulud beschrieben: dasselbe Wurmmuster, nur in größerem Maßstab wiederholt, weniger als ein Jahr nach dem ursprünglichen Vorfall. Der Mechanismus hatte sich nicht verändert. Auch die Abwehrmechanismen größtenteils nicht.
Drei npm-Wurm-Vorfälle, ein sich wiederholendes Muster: einen vertrauenswürdigen Herausgeber kompromittieren, dessen Zugangsdaten zur automatischen Verbreitung nutzen und darauf vertrauen, dass die Lücke zwischen Veröffentlichung und Erkennung durch die Community den Rest erledigt.
Das sich wiederholende Muster
Lässt man die Details außer Acht, so folgt jeder npm-Wurm-Vorfall denselben vier Mustern:
- Kontokompromittierung. Ein Veröffentlichungstoken eines Maintainers, npm loginoder die CI-Zugangsdaten werden gestohlen, in der Regel durch Phishing, ein durchgesickertes Geheimnis oder eine kompromittierte Abhängigkeit weiter oben in der Kette.
- Stille Injektion. Der Angreifer verbreitet eine neue Version eines legitimen, vertrauenswürdigen Pakets, in die bösartiger Code eingefügt wurde, oft innerhalb eines Postinstall- oder eines anderen Lebenszyklusskripts, das automatisch ausgeführt wird, sobald jemand das Paket installiert.
- Automatische Verbreitung. Wenn der kompromittierte Paketbetreuer auch andere Pakete kontrolliert oder wenn das bösartige Skript selbst weitere Zugangsdaten sammelt, breitet sich der Wurm ohne weiteres Zutun des Angreifers auf das nächste Paket und den nächsten Paketbetreuer aus.
- Die Erkennungsverzögerung. Das Paket ist weiterhin in der Registry verfügbar und kann von jedem installiert werden, bis es jemand bemerkt, meldet und entfernt wird. Diese Verzögerung – in manchen Fällen Stunden, in anderen Tagen – ist genau das Zeitfenster, das der Wurm benötigt.
Die Erkenntnis, dass dieser vierte Schritt für die Verteidigung entscheidend ist, liegt darin, diese Verzögerung bei der Erkennung zu verringern oder zu umgehen. Jede Strategie zur Abwehr eines npm-Wurm-Vorfalls zielt im Kern darauf ab, diese Verzögerung zu minimieren oder zu umgehen.
Ein Framework, das es wert ist, zitiert zu werden: SIPs Antwort auf das Cooldown-Problem
Nicht jede Reaktion auf dieses Muster stammt von einem Händler. Eine der deutlichsten ist: SIP, Mohammad-Ali A'râbis Sofortiger Sicherheitsplan, ein Fünf-Punkte-Notfallrahmen für Risiken in der Software-Lieferkette, der aus einer sehr praktischen Frage entstand, die am Ende einer SafeDev-Sitzung gestellt wurde: „Wenn wir nur ein paar Dinge tun können, was sollten wir zuerst tun?“
Die zweite Kontrollmaßnahme von SIP zielt direkt auf das Problem des npm-Wurms ab: Nicht geprüfte Abhängigkeiten werden mit einer fünftägigen Wartezeit eingefroren, und Lebenszyklusskripte werden deaktiviert, damit ein schädliches Postinstall-Skript während der Installation nicht automatisch ausgeführt werden kann. In der Praxis bedeutet das: min-release-age=5 und ignore-scripts=true in einem Projekt .npmrcDies wird in der CI-Umgebung erzwungen, damit eine Sperrdatei ein gestern veröffentlichtes Paket nicht unbemerkt auflösen kann. Es handelt sich um eine wirklich solide und unkomplizierte Kontrollmaßnahme, die genau die gleiche Erkennungsverzögerung behebt, von der jeder npm-Wurm-Vorfall abhängt. Mehr dazu:
Wo das Abkühlfenster noch eine Lücke lässt
Eine Abkühlphase ist eine Wette: Man hofft, dass die Community ein schädliches Paket bemerkt und meldet, bevor die Wartezeit abläuft. Meistens geht diese Wette auf. Ein erheblicher Anteil kompromittierter Pakete wird innerhalb der ersten Tage nach Veröffentlichung gemeldet, weshalb ein Zeitraum von fünf Tagen als Standardwert angemessen ist.
Ein npm-Wurm verhält sich jedoch nicht wie ein typisches Schadprogramm, und das ändert die Möglichkeiten und Grenzen einer festen Abklingzeit.
Vorbereitencise über Geschwindigkeit: Ein sich schnell verbreitender Wurm umgeht die Abklingzeit nicht. Wenn ein striktes Mindestalter für die Veröffentlichung festgelegt wird, sind Pakete, die während der ersten Welle veröffentlicht werden, immer noch zu neu, um in einen Build aufgenommen zu werden – unabhängig davon, wie viele Pakete der Wurm in der Zwischenzeit kompromittiert hat. Geschwindigkeit ist wichtig, aber nur für alle nachfolgenden Systeme, die keine Abklingzeit verwenden, und nicht, um eine bereits bestehende Abklingzeit zu umgehen.
Die eigentliche Einschränkung ist die Geduld. Eine sorgfältigere Nutzlast kann nach der Abkühlphase inaktiv bleiben und erst aktiviert werden, wenn einige Tage vergangen sind und das Paket den Status „vertrauenswürdig“ erreicht hat.cisDer Grund dafür ist, dass es weiß, dass eine Abklingzeit aktiv ist. In diesem Szenario reicht eine feste Abklingzeit allein nicht aus, und genau hier muss etwas wie MEWs evidenzbasierte Erkennung parallel dazu eingesetzt werden, nicht anstelle dessen.
Keiner der beiden Fehlermodi ist ein Denkfehler im SIP-Konzept. Eine Abklingzeit basiert auf der Erkennung durch die Community, und diese hat ihre Grenzen: Sie kann nur Fälle erfassen, die noch nicht gemeldet wurden. Diese Einschränkung ist nicht spezifisch für SIP, sondern eine strukturelle Grenze jeder Verteidigung, die auf eine Signatur, eine Warnung oder einen öffentlichen Bericht wartet, bevor sie reagiert.
Wie MEW die Lücke im Abklingzeitfenster schließt
Dies ist vorcisely die Lücke Xygenis Malware-Frühwarnung (MEW) MEW ist so konzipiert, dass es Bedrohungen zuverlässig abwehrt. Anstatt auf Meldungen aus der Community oder eine veröffentlichte Signatur zu warten, scannt MEW kontinuierlich NPM, PyPI und Maven, sobald neue Pakete und Versionen veröffentlicht werden. Dabei wird das Verhalten analysiert, anstatt es mit bekannten Bedrohungen abzugleichen. Wenn etwas verdächtig aussieht, wird es unter Quarantäne gestellt und der Befund von Sicherheitsforschern bestätigt, bevor er öffentlich bekannt wird.
Diese Unterscheidung ist für beide oben genannten Fehlermodi des npm-Wurms relevant. Bei einem sich schnell verbreitenden Wurm benötigt die Erkennung vor der Signatur nicht die fünftägige Wartezeit, die im Rahmen einer Abklingzeit angenommen wird. Bei einer geduldigen, ruhenden Payload analysiert MEW nicht Alter oder Reputation, sondern die tatsächliche Funktion des Codes. Daher bringt das Abwarten einer Abklingzeit einem Angreifer keinerlei Vorteile.
Die Abhängigkeits-Firewall von MEW erweitert dies bis zum Installationspunkt selbst und blockiert ein schädliches Paket in Echtzeit, selbst wenn es frühere Prüfungen passiert hat, und dieselbe Erkennungsebene deckt die CI/CD Eine Seite eines npm-Wurm-Vorfalls: das Muster „Branch entsperren, injizieren, erneut sperren“, das es einem Angreifer ermöglicht, bösartigen Code einzuschleusen. commit und dabei unauffällig ihre Spuren verwischen, wobei im Falle eines Falles eine vollständige Protokollierung erfolgen würde.
SIP und MEW beantworten dieselbe Frage, jedoch auf unterschiedlichen Ebenen.
Nichts davon macht die Cooldown-Steuerung von SIP falsch, und es sei ganz klar gesagt: Ein fünftägiger Cooldown mit deaktivierten Lifecycle-Skripten ist nach wie vor eine der schnellsten und kostengünstigsten Verteidigungsmaßnahmen, die ein Team gegen einen gewöhnlichen npm-Wurm-Vorfall ergreifen kann, und gehört in jeden ernsthaften Plan zur Absicherung der Lieferkette. Was er jedoch konstruktionsbedingt nicht leisten kann, ist, das zu erkennen, was die Community noch nicht entdeckt hat. Dafür ist eine kontinuierliche, verhaltensbasierte Erkennung erforderlich, die unterhalb des Cooldowns läuft, nicht anstelle desselben.
Die beiden Ansätze, übereinander geschichtet, decken beide Seiten desselben Problems ab: SIP erhöht die Härte des Builds pipeline, die Abhängigkeitssperre und das Container-Image um eine bekannte, offengelegte Bedrohungslandschaft herum, während die Vorsignaturerkennung von MEW die npm-Wurm-Vorfälle abdeckt, die noch nicht offengelegt wurden, also diejenigen, die ein Cooldown-Fenster nach seiner eigenen Logik nicht vorhersehen kann.
FAQ
Was ist ein npm-Wurm, in einem Satz?
Bösartiger Code, der auf npm veröffentlicht wird und sich automatisch auf andere Pakete ausbreitet, typischerweise durch Diebstahl der Zugangsdaten eines Paketbetreuers und deren Verwendung, um dieselbe Nutzlast an anderer Stelle einzuschleusen, ohne dass weitere Aktionen des Angreifers erforderlich sind.
Ist jedes bösartige npm-Paket ein npm-Wurm?
Nein. Ein schädliches Paket, das sich nicht selbstständig verbreitet, stellt zwar einen Lieferkettenangriff dar, ist aber kein Wurm. Charakteristisch für einen npm-Wurm-Vorfall ist die Selbstverbreitung: Eine Kompromittierung führt automatisch zur nächsten.
Verhindert eine Abklingzeit für Abhängigkeiten einen npm-Wurm?
Dies reduziert das Risiko erheblich, da die meisten schädlichen Pakete innerhalb der ersten Tage nach ihrer Veröffentlichung gemeldet werden. Eine solche Verzögerung setzt jedoch auf die Geschwindigkeit der Erkennung durch die Community, und ein sich schnell verbreitender oder absichtlich inaktiver npm-Wurm kann gezielt so entwickelt werden, dass er dieses Zeitfenster umgeht.
Was genau fängt einen npm-Wurm vor Ablauf einer Abklingzeit ab?
Kontinuierliches, verhaltensbasiertes Scannen, das weder auf einer Signatur noch auf einem öffentlichen Bericht basiert – genau diese Lücke sollen Tools zur Erkennung von Signaturen wie MEW von Xygeni schließen.
