Analyse des npm-Supply-Chain-Angriffs

Es ist schon eine Weile her seit unserem letzten Blogartikel, und in dieser Zeit ist vieles geschehen, doch die Ereignisse vom 8. September 2025 in der JavaScript-Welt verdienen besondere Aufmerksamkeit. An diesem Tag wurden 18 populäre npm‑Pakete wie debug und chalk mit schadhaftem Code versehen. Die betroffenen Pakete werden jede Woche Millionen Mal heruntergeladen und bilden das Fundament vieler Web‑ und Server‑Anwendungen. In diesem Beitrag analysieren wir, wie der Angriff ablief, was genau npm ist, warum sich der Vorfall so schnell ausbreiten konnte und was Entwickler:innen aus diesem Vorfall lernen können.

Was genau ist passiert?

Am 8. September 2025 nutzten Angreifer eine Phishing-Attacke gegen den Maintainer „qix“. Sie verschickten eine glaubhaft wirkende E-Mail von einer gefälschten Domain (npmjs.help) und forderten dazu auf, die Zwei-Faktor-Authentisierung zurückzusetzen. Durch die Preisgabe des Benutzerkontos konnten die Angreifer neue kompromittierte Versionen von 18 weit verbreiteten Paketen hochladen. 

Die schadhaften Versionen wurden kurz nach 13:00 UTC veröffentlicht und gegen 15:00 UTC von der Community entdeckt. Innerhalb von etwa zwei Stunden konnten die Maintainer und das npm-Sicherheitsteam die kompromittierten Releases wieder entfernen. Trotz dieses kurzen Zeitfensters hat jeder Entwickler oder jede Build-Pipeline, die das Paket in dieser Zeit installierte, die Schadsoftware unwissentlich in Projekte eingebaut. 

Was ist npm und warum ist es so kritisch?

Die Node Package Manager‑Registry (npm) ist das Herzstück des JavaScript‑Ökosystems. Sie stellt mehr als eine Million Pakete zur Verfügung und wird von unzähligen Projekten genutzt. Die Pakete debug und chalk dienen z. B. als leichtgewichtige Logging‑Bibliothek bzw. zum Formatieren von Terminal‑Ausgaben. Laut Cycode sitzen diese Bibliotheken unter einem grossen Teil des Node‑Ökosystems. Deshalb kann die Kompromittierung einer einzigen Abhängigkeit auf viele Projekte durchschlagen.

Ein wichtiger Begriff sind transitive Abhängigkeiten. Das sind Bibliotheken, die indirekt in ein Projekt gelangen, weil eine direkt eingebundene Bibliothek ihrerseits weitere Pakete benötigt. Gemäss Codacy stammen etwa 95 % der bekannten Schwachstellen in Open‑Source‑Software aus solchen transitiven Abhängigkeiten. Die Schwierigkeit besteht darin, dass diese Abhängigkeiten in der Regel nicht explizit in der package.json aufgelistet sind. Dies ist die Datei, in welcher definiert wird, welche direkten Abhängigkeiten ein npm-Projekt hat.

Das folgende Bild zeigt einen kleinen Ausschnitt aus dem Abhängigkeitsbaum des Pakets react-scripts. Dieses Paket steckt hinter Create React App und enthält alle Skripte und Konfigurationen für Webpack, Babel, ESLint, Jest und andere Tools. Auch react-scripts hat mehrere transitive Abhängigkeiten zu debug:

Die Darstellung ist nur ein kleiner Ausschnitt – der komplette Graph erstreckt sich über hunderte Pakete und wird schnell unübersichtlich. Unter npmgraph.js.org/?q=react‑scripts kann man selbst hineinzoomen und durch die Knoten klicken. Dieses Beispiel zeigt anschaulich, wie schon ein einziges Paket eine Lawine transitiver Abhängigkeiten nach sich ziehen kann und dass jedes davon das Potenzial hat, Schadcode in ein Projekt einzuschleusen.

Wie konnte sich der Angriff so schnell verbreiten?

Moderne Teams setzen auf CI/CD‑Pipelines und Tools wie Dependabot oder Renovate, die automatisch prüfen, ob es neue Versionen von Abhängigkeiten gibt, und dafür Pull-Requests erstellen, um Abhängigkeiten automatisch zu aktualisieren. Dadurch bleiben Projekte ohne viel manuellen Aufwand aktuell. In vielen Projekten werden diese automatischen Pull‑Requests sogar ohne manuelle Kontrolle gemergt. Das spart zwar Zeit, erhöht aber die Gefahr, dass kompromittierte Versionen unbemerkt in das Projekt gelangen. Aufgrund der enormen Downloadzahlen und der Tatsache, dass transitive Abhängigkeiten unbemerkt mitinstalliert werden, ist die potenzielle Reichweite also riesig.

Ein kurzer Blick auf GitHub zeigt, wie schnell sich kompromittierte Versionen wie debug@4.4.2 oder chalk@5.6.1 automatisch in Projekten wiederfanden. Mit gezielten Suchen wie

 is:pr "debug" "4.4.2" created:2025-09-08..2025-09-09

oder

 is:pr "chalk" "5.6.1" created:2025-09-08..2025-09-09 

 lassen sich Dutzende automatisch erstellte Pull‑Requests mit direkten Abhängigkeiten finden, welche durch Bots wie Dependabot oder Renovate erzeugt wurden. 

Diese PRs wurden wenige Stunden nach Veröffentlichung der schadhaften Versionen erzeugt. Auch wenn viele Projekte den PR nicht gemerged haben, zeigt das Beispiel, wie schnell solche Änderungen Einzug halten könnten. Ein solcher PR könnte zum Beispiel folgendermassen aussehen:

Der Dependency-Bot erkennt, dass eine neue Version des Pakets verfügbar ist, fügt diese automatisch in das package.json ein und erstellt einen Pull Request. Besonders brisant wird es bei PRs, die automatisch gemerged wurden – etwa durch konfigurierte Auto‑Merge‑Policies.

Mit der erweiterten Suche

 is:pr "debug" "4.4.2" created:2025-09-08..2025-09-09 is:merged 

findet man tatsächlich auch Fälle, in denen kompromittierte Versionen automatisch übernommen wurden:

Ein besonders interessantes Beispiel: Im Projekt eslint-config-extender wurde debug@4.4.2 trotz Warnung von Socket Security automatisch gemerged. Socket meldete, dass das Paket verschleierten Code enthält:

Diese Beispiele zeigen deutlich, wie hoch die Geschwindigkeit und Automatisierung in modernen Softwareprozessen ist und wie leicht dabei Schadcode eingeschleust werden kann, wenn Vertrauen in Update‑Bots nicht mit Schutzmechanismen kombiniert wird.

Natürlich sind Tools wie Dependabot und Renovate nicht das Problem – ganz im Gegenteil: In Anbetracht der schieren Menge an Abhängigkeiten sind automatisierte Updates heutzutage unverzichtbar. Sie helfen Teams, Sicherheitslücken schneller zu schliessen und Versionskonflikte frühzeitig zu erkennen.

Umso wichtiger ist es, eine sinnvolle Balance zu finden: Jedes Team muss selbst entscheiden, ob es den Schwerpunkt auf schnelle Sicherheitsupdates legt oder ob es lieber Verzögerungen in Kauf nimmt, um Änderungen gründlicher zu prüfen. Das ist eine schwierige Aufgabe. Sicherheitsplattformen wie Socket.dev können dabei unterstützen, indem sie automatisch auf Warnsignale wie Obfuskation oder ungewöhnliche Aktivitäten reagieren. Allerdings ist es in der Praxis oft schwierig, wirklich schadhaften Code auf diese Weise zuverlässig zu erkennen.

Sobald kompromittierte Versionen jedoch bekannt sind, können sie über konsequentes SBOM-Management (Software Bill of Materials) zuverlässig identifiziert werden. Eine gepflegte und überprüfbare SBOM ist daher heute absolut unverzichtbar, um betroffene Abhängigkeiten schnell aufzuspüren und Updates gezielt einzuspielen.

Wie wurde der Angriff entdeckt und behoben?

Die Community reagierte schnell. Bereits wenige Stunden nach der Veröffentlichung meldeten Entwickler auf GitHub, dass die neuen Versionen von debug und chalk obfuskierten Code enthielten. Sicherheitsteams wie Aikido und Upwind publizierten Warnungen, und das npm‑Sicherheitsteam entfernte die kompromittierten Versionen umgehend. Der Maintainer bestätigte öffentlich die Phishing‑Attacke und arbeitete mit npm zusammen, um die sauberen Versionen zu veröffentlichen. Semgrep weist darauf hin, dass viele der kleineren Pakete keine Downloads verzeichneten, bevor sie aus dem Registry entfernt wurden.

Wie schnell manche Projekte reagierten, zeigt der Pull‑Request #1342 im MetaMask‑SDK:
Bereits am 9. September 2025, nur wenige Stunden nach Bekanntwerden des Vorfalls, wurde dort die debug‑Abhängigkeit auf die letzte sichere Version 4.3.4 festgenagelt („pinned“):

Im PR‑Kommentar erklärt der Maintainer, dass MetaMask selbst zwar nicht direkt betroffen war, aber Entwickler:innen, die auf das SDK bauen, durch die automatische Auflösung (^4.3.4) womöglich die kompromittierte Version 4.4.2 installiert haben.

Der PR ändert die Datei package.json so, dass die debug‑Version fix auf 4.3.4 gesetzt wird – also auch zukünftige Versionen wie 4.4.3 oder 5.0.0 ignoriert werden:

Diese proaktive Reaktion zeigt, wie wichtig es ist, auch nicht direkt betroffene Projekte zu auditieren – insbesondere dann, wenn häufig genutzte SDKs, Frameworks oder DevTools betroffen sein könnten.

Der Schadcode und seine Wirkung

Der eingeschleuste Schadcode war stark obfuskiert, wurde bereits beim Laden der betroffenen Pakete aktiv und zielte hauptsächlich auf ein Ding ab: Krypto-Diebstahl durch sogenanntes Address-Switching. Findet der Code Zeichenketten, die wie Wallets aussehen, können diese durch die Angreifer-Adressen ersetzt werden. Damit entsteht auch ohne klassische „Exfiltration“ ein reales Risiko für finanzielle Schäden, sobald Gelder an scheinbar legitime Adressen gesendet werden.

Wir haben ein Skript geschrieben, das die in der Payload hartkodierten Wallets extrahiert und basic-On-Chain-Signale abfragt.

Ergebnis der Extraktion

ETH: 67

BTC: 81

SOL: 19

TRX: 40

LTC: 40

BCH: 40

Total: 287

Die meisten Adressen weisen keine Transaktionen auf, es gab jedoch vier Einträge, bei welchen gewisse Mengen verbucht wurden:

ETH : 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976

9 Transaktionen mit $453.55

ETH: 0xa4134741a64F882c751110D3E207C51d38f6c756

1 Transaktion mit $1.36

SOL: 5VVyuV5K6c2gMq1zVeQUFAmo8shPZH28MJCVzccrsZG6

8 Transaktionen mit $49.25

SOL : 98EWM95ct8tBYWroCxXYN9vCgN7NTcR6nUsvCx1mEdLZ

1 Transaktion mit $2.388

In Summe kommen diese vier sichtbaren Treffer auf rund $506 in 19 Transaktionen zum Zeitpunkt dieses Artikels. Mehrere Explorer markieren die Adressen bereits mit einem Warnhinweis, u. a. Etherscan:

Diese Beobachtungen stützen die Einschätzung, dass die Kampagne auf das Umleiten von Zahlungen ausgelegt war. Auch wenn der direkte finanzielle Schaden im Verhältnis sehr gering ausfällt, ist der indirekte „Denial-of-Service“-Effekt auf Entwickler:innen erheblich: Immer wieder entsteht ein hoher Aufwand, um kompromittierte Pakete zu identifizieren, Abhängigkeiten zu prüfen und Systeme abzusichern.

Supply‑Chain‑Angriffe sind kein Einzelfall

Der npm‑Vorfall ist Teil einer länger werdenden Liste spektakulärer Lieferkettenangriffe:

• XZ Utils‑Backdoor (März 2024) – Ein Angreifer namens „Jia Tan“ schmuggelte über mehrere Jahre ein Backdoor in die liblzma‑Bibliothek von XZ Utils ein. Die Hintertür ermöglichte Remote‑Code‑Ausführung über ssh und wurde zufällig bei einer Performance‑Analyse entdeckt. Glücklicherweise waren die kompromittierten Versionen 5.6.0 und 5.6.1 noch nicht in grossen Distributionen ausgerollt.
• Rspack/Vant (Dezember 2024) – Angreifer stahlen npm‑Tokens und veröffentlichten neue Versionen der Pakete @rspack/core, @rspack/cli und vant mit obfuskiertem Code, der den Monero‑Miner XMRig auf befallenen Systemen startete.
• Dependabot‑Impersonation (September 2023) – Angreifer verwendeten gestohlene Zugriffs‑Token, um hunderte von GitHub‑Repos mit bösartigem Code zu füttern. Die Commits wurden als Dependabot‑PRs getarnt und enthielten Code, der externen Schadcode nachlud. Viele Entwickler vertrauten dem Namen und führten keine Prüfung durch.

Phishing – Entwickler:innen als Ziel

Der rote Faden durch alle genannten Angriffe ist Social Engineering. Die npm‑Kampagne begann mit einer überzeugend gefälschten E‑Mail, die nach einem 2FA‑Reset verlangte. Auch die Dependabot‑Impersonation nutzte gestohlene Zugangsdaten. Entwicklerinnen und Entwickler werden gezielt angesprochen, weil sie Zugang zu kritischen Komponenten haben.

Schutz bietet hier nur Wachsamkeit: Unbekannte Domains, ungewöhnliche Anfragen nach 2FA‑Codes oder nicht erwartete Pull‑Requests sollten Misstrauen wecken. Unser Team bei avantguard bietet Phishing‑Simulationen an, um Teams auf genau solche Szenarien vorzubereiten.

Fazit

Der 8. September 2025 zeigt eindrucksvoll, wie verletzlich das Open‑Source‑Ökosystem ist. Eine einzige kompromittierte Maintainer‑Identität kann Milliarden Downloads und unzählige Projekte gefährden. Gleichzeitig beweist die schnelle Reaktion der Community, dass Transparenz und Zusammenarbeit funktionieren: Innerhalb von zwei Stunden waren die bösartigen Pakete entfernt und der finanzielle Schaden konnte soweit in Grenzen gehalten werden.

Dennoch bleibt die Aufgabe, die Software‑Lieferkette zu stärken. Dazu gehören eine vollständige Sicht auf alle Abhängigkeiten (SBOM), die Kontrolle über automatisierte Updates, die Absicherung von Entwicklerkonten und eine gesunde Skepsis gegenüber unerwarteten E‑Mails und Pull‑Requests.

Angriffe wie der auf npm und XZ Utils werden uns weiter begleiten. Entscheidend ist, dass wir daraus lernen und unsere Prozesse, Tools und Teams kontinuierlich verbessern.