Alle Beiträge

npm-Provenance ist kein Sicherheitscheck: was der tensorlake-Wurm zeigt

Node.js · 4 Min. Lesezeit ·

Das grüne Provenance-Badge an einem npm-Paket sagt dir, wo das Paket gebaut wurde. Es sagt dir nicht, dass der Code sicher ist. Laut dem Incident-Tracker pwn.watch wurde tensorlake@0.5.144 am 8. Oktober 2026 aus dem echten GitHub-Repository des Projekts veröffentlicht, mit npm-Provenance, und enthielt einen preinstall-Hook, der einen Wurm nach Art von Shai-Hulud installiert, der Zugangsdaten stiehlt. Wenn dein Team Provenance als Vertrauenssignal behandelt, ist das der Fall, den es sich anzusehen lohnt, denn das Badge war echt.

Was der Tracker meldet

Alles in diesem Abschnitt ist die Zusammenfassung des Trackers, die Darstellung eines einzelnen Aggregators; prüfen solltest du vor dem Handeln das Advisory des Pakets selbst. Der Tracker führt den Eintrag als teilweise gepatcht. Er schreibt, der Hook sammle Secrets von npm, GitHub, Cloud, SSH und KI-Tools ein, verbreite sich auf andere Pakete und installiere einen Watcher namens "gh-token-monitor", der das Home-Verzeichnis löscht, wenn das gestohlene GitHub-Token widerrufen wird. Sein Rat: 0.5.143 pinnen und diesen Watcher entfernen, bevor du Tokens rotierst. Der letzte Punkt dreht den üblichen Reflex um, zuerst zu widerrufen, und genau deshalb ist er wichtig.

Was Provenance beweist und was nicht

Das ist allgemeines Wissen darüber, wie Provenance funktioniert. Provenance ist eine signierte Aussage, dass ein bestimmtes Repository und ein bestimmter Workflow das Paket erzeugt haben. Sie schließt eine Lücke gut: Wer mit einem gestohlenen Token vom Laptop aus ein Imitat veröffentlicht, kann sie nicht fälschen. Sie sagt nichts darüber, ob der Code in diesem Repository zu diesem Zeitpunkt harmlos ist. Kommt ein Angreifer in die Build-Pipeline oder in das Konto eines Maintainers, wird das bösartige Release aus dem echten Repository gebaut und trägt echte Provenance.

Code, der committet wurde Welches Repository Welcher Workflow Genau diese Paketdatei Provenance deckt diese Glieder ab nicht abgedeckt: ist der Code harmlos? ebenfalls nicht: Eine gekaperte Pipeline oder ein Maintainer-Token erzeugt trotzdem ein Release mit gültiger Provenance
Provenance beantwortet "wo wurde das gebaut", nie "ist dieser Code sicher".

GitHub zieht auf der Veröffentlichungsseite die Schrauben an. Laut Changelog laufen nicht validierte npm-Trusted-Publishing-Konfigurationen jetzt nach 48 Stunden ab, Trusted-Publishing-Tokens aus issue_comment-Events werden abgelehnt, und bei npm stage publish muss ein Maintainer die erste Version eines neuen Pakets freigeben. GitHub schreibt außerdem, dass Malware zunehmend bei der Installation zuschlägt und auf CI-Hosts und Arbeitsrechnern Zugangsdaten abgreift, ohne dass deine App den Code des Pakets je ausführt. Genau so sieht dieser Vorfall aus, und deshalb muss die Abwehr bei der Installation ansetzen.

Der Weg von npm install zu deinen Secrets

Wieder allgemeines Wissen: preinstall- und install-Skripte laufen während npm install mit den Rechten deines Users. Was deine Shell lesen kann, kann also auch das Skript lesen. Auf einem Laptop sind das deine SSH-Keys und deine Cloud-Konfiguration. Auf einem CI-Runner ist es jedes Secret, das in den Job injiziert wird.

npm install Holt ein neues Release Führt sein Install-Skript aus Liest deine Secrets Schnitt 1 Lockfile, Wartezeit Schnitt 2 --ignore-scripts Schnitt 3 keine Secrets dort, wo du installierst
Drei Stellen, an denen sich die Kette brechen lässt, jede nützlich, auch wenn die anderen versagen.

Schnitt 1: Entscheide, was installiert wird. Committe den Lockfile und installiere daraus, damit ein neues Release nur dann ankommt, wenn du es willst. Eine Wartezeit, also keine Releases übernehmen, die jünger als ein paar Tage sind, verschafft Zeit, weil bösartige Releases oft innerhalb weniger Tage auffallen. GitHubs Package-Firewall, in der Public Preview nur für Enterprise Cloud und npm, bietet eine solche Wartezeit konfigurierbar an. Schnitt 2: Install-Skripte standardmäßig nicht ausführen. npm ci --ignore-scripts überspringt sie; manche Pakete brauchen ihre wirklich, also erlaube diese gezielt. Schnitt 3: Secrets vom Installationsschritt fernhalten. Ein CI-Job, der Abhängigkeiten installiert, braucht deine Deploy-Keys nicht in seiner Umgebung.

npm ci --ignore-scripts
npm ls tensorlake
Provenance sagt dir, wer ein Paket gebaut hat, nicht, ob du es ausführen solltest: Pinne aus einem Lockfile und lass Install-Skripte deine Secrets nicht sehen.

Wenn tensorlake 0.5.144 auf einer Maschine lief

Die allgemeine Reihenfolge: Maschine oder Runner isolieren, herausfinden, was gelaufen ist, dann von einer sauberen Maschine aus jedes Secret rotieren, das es lesen konnte. In diesem Fall gilt laut Tracker: Such den Token-Watcher und entferne ihn, bevor du das GitHub-Token widerrufst. Gleich jeden Schritt mit dem Advisory des Pakets selbst ab, nicht nur mit dieser Zusammenfassung.

Quelle: der Incident-Tracker pwn.watch, Eintrag "tensorlake@0.5.144 npm Shai-Hulud worm with hostage GitHub token".

Notizen der Leser

  1. Noch keine Notizen. Die erste ist immer die mutigste.
Baust du etwas Ähnliches? Ich kann helfen. Schreib mir auf WhatsApp