Ein npm-Paket, das die privaten Schlüssel stahl

Ein npm-Paket mit rund 50.000 wöchentlichen Downloads verschickte für kurze Zeit die privaten Schlüssel seiner Nutzer. Das offizielle Injective-SDK trug eine als Telemetrie getarnte Funktion, die Wallet-Keys und Mnemonics abgriff. Entdeckt hat es der Sicherheitsdienst Socket. Der Fall zeigt, wie eine einzige manipulierte Abhängigkeit einen ganzen Build vergiftet.

Verwandt: Ein signierter Treiber macht den Endpunktschutz blind  ·  Wenn Angreifer schneller sind als der Patch

Was im Injective-SDK steckte

Was ist ein Supply-Chain-Angriff? Ein Angriff auf die Lieferkette zielt nicht direkt auf ein Unternehmen, sondern auf eine Komponente, die viele Unternehmen verbauen. Wird eine öffentliche Abhängigkeit manipuliert, fließt der Schadcode über den normalen Installationsweg zu jedem, der das Paket zieht.

Im aktuellen Fall betraf es die TypeScript-Bibliothek @injectivelabs/sdk-ts, ein Werkzeug für Anwendungen rund um die Injective-Blockchain. Eine manipulierte Version brachte eine Funktion mit, die sich als Telemetrie ausgab. Tatsächlich griff sie Zugangsdaten ab. Der Aufruf zum Ableiten einer Wallet aus einer Mnemonic protokollierte die vollständige Phrase, der Aufruf aus einem privaten Schlüssel dessen Material.

Die abgegriffenen Daten wurden base64-kodiert und still per Netzwerkanfrage an einen verschleierten Endpunkt geschickt. Für den Entwickler blieb der Vorgang unsichtbar. Das Paket zählt rund 50.000 Downloads pro Woche. Die manipulierte Version wurde zusätzlich über 17 weitere Injective-Pakete verteilt. Wer eines davon einband, war betroffen, ohne die eigentliche Bibliothek je direkt installiert zu haben.

Wie die Schleuse in den Code kam

Der Weg hinein führte über das offizielle Projekt selbst. Die Schadfunktion gelangte über Commits in das GitHub-Repository, abgesetzt über ein Konto mit langer Beitragshistorie. Ein solches Konto weckt keinen Verdacht. Genau das macht die Übernahme eines etablierten Mitwirkenden so wirksam.

Auffällig war der Vorlauf. Bereits Wochen vor der Veröffentlichung tauchte im Repository ein Testzweig mit dem sprechenden Namen einer Hintertür-Prüfung auf. Solche Spuren sind im Nachhinein deutlich, im Alltag eines aktiven Open-Source-Projekts aber leicht zu übersehen.

Warum das jeden Build betrifft

Der Vorfall trägt ein Krypto-Etikett, das Muster ist jedoch universell. Jede moderne Anwendung zieht Dutzende bis Hunderte fremder Pakete, oft über mehrere Ebenen. Ein einziges kompromittiertes Glied genügt. Dann läuft der Schadcode mit den Rechten des Builds.

Besonders heikel sind transitive Abhängigkeiten. Ein Team bindet ein Paket bewusst ein und erbt damit dessen komplette Kette, die es nie geprüft hat. Wer Zugangsdaten, Tokens oder Schlüssel in einer Entwicklungsumgebung mit ungeprüften Abhängigkeiten hält, gibt einem solchen Angriff genau das, was er sucht.

Was Entwickler und Security-Teams jetzt tun

Die erste Frage lautet: Läuft eine betroffene Version im eigenen Haus? Ohne verlässliches Abhängigkeits-Inventar bleibt die Antwort ein Ratespiel. Erst danach greifen die technischen Hebel.

Werkzeuge zur Abhängigkeitsanalyse verkürzen die Reaktionszeit, weil sie ein manipuliertes Paket melden, bevor es breit ausgerollt ist. Der eigentliche Hebel bleibt aber organisatorisch: Wer seine Lieferkette nicht kennt, kann sie nicht schützen.

Ein Testfall für die Lieferkette

Injective erklärte, den Vorfall in unter einer Stunde behoben und keinen Nutzer geschädigt zu haben. Diese Einordnung stammt vom Anbieter selbst. Unabhängig davon bleibt die Lehre bestehen: Die schnelle Reaktion eines Projekts entbindet die Anwender nicht davon, ihre eigene Kette zu sichern.

Für Unternehmen mit Pflichten aus NIS2 oder DORA ist Lieferketten-Risiko kein abstraktes Thema mehr. Beide Rahmenwerke verlangen, dass Organisationen die Risiken ihrer Zulieferer und Komponenten steuern. Ein manipuliertes Paket im eigenen Build ist genau der Fall, für den diese Vorgaben geschrieben wurden.

Häufige Fragen

Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.

Was ist ein Supply-Chain-Angriff?

Ein Angriff auf die Lieferkette manipuliert eine Komponente, die viele Ziele gemeinsam nutzen, etwa eine öffentliche Software-Abhängigkeit. Der Schadcode fließt dann über den normalen Installationsweg zu allen, die das Paket einbinden.

Bin ich betroffen, wenn ich das SDK nie direkt installiert habe?

Möglich. Die manipulierte Version wurde über 17 weitere Pakete verteilt. Wer eines davon einband, erbte die Abhängigkeit transitiv, ohne die eigentliche Bibliothek je direkt zu ziehen.

Reicht das Aktualisieren auf die bereinigte Version?

Als erster Schritt ja, als einziger nein. Schlüssel und Mnemonics, die durch eine betroffene Version liefen, gelten als kompromittiert. Sie gehören rotiert, Guthaben sollte bewegt werden.

Wie kam der Schadcode in ein offizielles Projekt?

Über Commits eines Kontos mit langer Beitragshistorie im offiziellen Repository. Ein etablierter Mitwirkender weckt keinen Verdacht, was die Übernahme eines solchen Kontos besonders wirksam macht.

Was schützt am wirksamsten vor solchen Angriffen?

Ein bekanntes Abhängigkeits-Inventar, feste Lockfiles, geprüfte Herkunftsnachweise und Signaturen sowie eng geschnittene Rechte im Build. Dazu keine langlebigen Secrets in Umgebungen mit ungeprüften Abhängigkeiten.

Lesetipps der Redaktion

LesetippOAuth-Token-Diebstahl: Wie Angreifer MFA aushebelnLesetippWie ein Ransomware-Angriff abläuftLesetippWas EDR und XDR wirklich unterscheidet

Mehr aus dem MBF Media Netzwerk

cloudmagazinZum ersten Mal kann man einer KI beim Denken zusehenMyBusinessFutureKI im Mittelstand vom Pilot zur SkalierungDigital ChiefsDie IT entscheidet, ob der Spin-off sich auszahlt

Bildquelle: KI-generiert (Juli 2026)