SUPPLY-CHAIN-HORROR im npm-Registry! Forscher melden einen SELBSTVERMEHRENDEN Wurm in falschen pgserve-Versionen. Der Bösewicht: Postinstall-Hook, Token-Klau, automatische Verbreitung. Was harmlos klingt, kann deine ganze Build-Pipeline kompromittieren. JETZT prüfen.
UNGLAUBLICH: Der Wurm KENNT deinen Namen
So läuft der Angriff: Du installierst pgserve über npm — eigentlich ein PostgreSQL-Server-Helper für Node. In der bösen Version steckt ein Postinstall-Skript. Es legt ein verstecktes _runtime-Verzeichnis an, das eine obfuskierte JavaScript-Payload enthält. Diese Payload sucht in deinem Home-Verzeichnis nach .npmrc, extrahiert deine npm-Auth-Tokens — und schickt sie an einen Discord-Webhook.
Aber damit nicht Schluss. Die Payload VERÖFFENTLICHT automatisch infizierte Patch-Versionen anderer npm-Pakete, an denen du Maintainer bist. Heißt: Aus einem infizierten Entwickler werden über Nacht Dutzende infizierte Pakete. Klassischer Wurm. Der Vergleich der Sicherheitsforscher: Mini-Shai-Hulud — eine kleinere Variante des SAP-Wellen-Angriffs vom Jahresanfang.
SCHOCK-MOMENT: Wie merkst du, dass es dich erwischt hat?
Indikatoren, auf die du sofort schauen solltest:
- Mails von npm über veröffentlichte Versionen, die du NICHT selbst publiziert hast.
- Frische Patch-Versionen deiner eigenen npm-Pakete in den letzten zwei Wochen.
- In
node_modules/pgserveein Ordner namens_runtime. - Ungewöhnlicher ausgehender Traffic auf
discord.com/api/webhooks/oder fremde Telegram-Hosts. - Token-Rotation in deinem CI-System schlägt plötzlich fehl, weil ein Token „bereits verwendet“ wird.
SOFORT-PLAN: So räumst du auf
1. Löschen. Bösartige pgserve-Version aus package.json raus, node_modules komplett wegwerfen, lockfile neu erzeugen. 2. Rotieren. Alle npm-Tokens, GitHub-PATs und CI-Secrets, die in der Maschine lagen, sofort widerrufen und neu ausstellen. 3. Aufräumen. Eigene npm-Pakete der letzten 14 Tage auf unerwartete Releases prüfen — ggf. npm unpublish innerhalb der 72-Stunden-Frist nutzen. 4. Kommunizieren. Wenn andere Maintainer deiner Pakete betroffen sein könnten, schreib sie sofort an. Schweigen ist hier KEIN Schutz, sondern Beihilfe.
EXTRA-TIPP: Wie du den Mist in Zukunft vermeidest
Ein paar Stellschrauben helfen JEDEM Node-Setup:
npm config set ignore-scripts true— Postinstall-Skripte global deaktivieren, wenn du sie nicht brauchst.- Provenance-Verifikation aktivieren:
npm audit signaturesin der CI laufen lassen. - Pin auf exakte Versionen, kein
^-Caret bei kritischen Paketen. - Abhängigkeits-Lockfile in CI erzwingen —
npm cistattnpm install. - Token mit minimalem Scope. Ein npm-Token für die ganze Pipeline ist 2026 keine gute Idee mehr.
FAZIT: Postinstall ist kein Sandkasten
npm hat seit Jahren ein strukturelles Problem: Jedes installierte Paket bekommt unbeschränkten Code-Ablauf. pgserve ist nicht die erste Welle — Lightning-PyPI vor zwei Wochen war eine Schwester-Aktion. Bis npm und PyPI Postinstall wirklich sandboxen, gilt: Misstrauisch bleiben, regelmäßig auditieren, Tokens rotieren. Sicherheit ist hier kein Feature, sondern eine tägliche Hygiene.