Wie 18 Pakete eine Hintertür bekamen
Um 20:24 UTC am 8. Juli 2026 übergab eine Wallet, die den neuesten Build von @injectivelabs/sdk-ts lud, ihre Seed-Phrase still an einen Angreifer. Der erste bösartige Commit war gerade eingegangen und blieb rund 49 Minuten aktiv, bevor jemand es bemerkte.
Die Angreifer brachen sich nicht mit Gewalt Zugang. Sie nutzten das GitHub-Konto eines langjährigen, vertrauten Beitragenden, um drei Commits zu pushen, die das SDK in Version 1.20.21 mit einer Hintertür versahen, dazu 17 abhängige Pakete, die genau auf diese Version festgelegt waren. Achtzehn Pakete trugen insgesamt dasselbe Gift. Die Hintertür kaperte PrivateKey.fromMnemonic() und PrivateKey.fromHex(), sodass sie BIP-39-Seed-Phrasen und private Schlüssel in dem Moment abgriff, in dem eine Wallet startete.
Etwa 310 Downloads erfolgten, bevor der Betreuer es bemerkte, zurücknahm und ein sauberes 1.20.23 auslieferte. Injective Labs sagt, es seien keine Nutzergelder verloren gegangen. Die bösartige Version wurde auf npm als veraltet markiert statt entfernt, sodass sie als Warnhinweis im Register verbleibt.
Die vertraute Pipeline war die Schwachstelle
Die Schutzmaßnahme war der Lieferweg. Die bösartige Version reiste über die eigene Vertrauenspublisher-Pipeline von Injective Labs auf npm, den OIDC-Pfad, der genau dafür gebaut wurde, das Risiko eines gestohlenen Publishing-Tokens zu beseitigen.
Das ist der unangenehme Teil. OIDC-Vertrauenspublishing heißt, dass ein Paket ohne langlebigen npm-Token freigegeben werden kann, den man stehlen könnte, was ein echter Sicherheitsgewinn ist. Aber es heißt auch, dass ein kompromittiertes menschliches Konto plus ein automatisierter Build dieses Vertrauen zum Angriffsweg macht. Es gab keinen Token zum Abgreifen, weil die Pipeline selbst die Signatur setzte, und die Pipeline vertraute dem Konto, das GitHub für legitim erklärte.
Was Sie in Ihren eigenen Abhängigkeiten prüfen sollten
Die Lehre hier ist allgemein, nicht auf Krypto beschränkt. Jeder Verantwortliche, der Software ausliefert, erbt genau diese Angriffsfläche über transitive Abhängigkeiten, die Pakete, von denen Ihre Pakete abhängen und die Sie nie direkt ausgewählt haben.
Legen Sie Ihre transitiven Abhängigkeiten auf geprüfte Versionen fest und scannen Sie sie, damit ein heimlicher Austausch bei einer festgelegten Version als Änderung auffällt statt durchzurutschen. Behandeln Sie Vertrauenspublisher-Automatik als Reduzierung eines Risikos, nicht als Beseitigung aller, denn der Weg über das kompromittierte menschliche Konto bleibt offen. Und rotieren Sie jedes Geheimnis, jeden Schlüssel und alle Zugangsdaten, die durch einen nun verdächtigen Build liefen, in der Annahme, sie wurden gesehen.
Weiterlesen: Progress: ShareFile-Kunden sollen abschalten | Eine Defender-Lücke gibt Nutzern volle Kontrolle
