Stellen Sie sich vor, Sie bestellen ein fertiges Möbelstück nach Hause. Der Lieferant klingelt, schiebt Ihnen das Paket in die Diele und sagt:

"Übrigens, ich darf jetzt auch noch durch Ihre Wohnung gehen, mir Ihren Briefkasten anschauen und schnell einen Blick in Ihr Schlafzimmer werfen."

Klingt absurd, oder? Genau das passiert aber in vielen Entwicklerprojekten täglich, nur eben digital. Der Befehl npm install ist ein solcher Lieferant. Und in diesem Artikel schauen wir uns gemeinsam an, warum er es verdient hat, dass Sie ihm in Zukunft sehr viel genauer auf die Finger sehen.

Warum dieses Thema gerade jetzt so wichtig ist

In den letzten Monaten haben sich die Angriffe auf das npm-Ökosystem dramatisch verändert. Was früher gelegentlich vorkam, ist heute eine systematische Bedrohung.

Wer JavaScript- oder TypeScript-Projekte baut, kommt um npm-Pakete kaum herum. Genau diese Selbstverständlichkeit machen sich Angreifer zunutze.

Sie zielen nicht mehr auf Ihre Anwendung selbst, sondern auf den Weg, den der Code zu Ihnen nimmt, die sogenannte Software-Lieferkette.

Was Sie aus diesem Artikel mitnehmen werden

Wir gehen Schritt für Schritt vor. Zuerst klären wir, was bei npm install technisch eigentlich passiert. Dann schauen wir uns echte Fälle aus den Jahren 2025 und 2026 an.

Zum Schluss bekommen Sie eine handfeste Checkliste, mit der Sie Ihre Projekte spürbar sicherer machen können, auch wenn Sie kein Sicherheits-Experte sind.

Der unscheinbare Befehl mit weitreichenden Folgen

Wenn Sie in Ihrem Terminal npm install eintippen, fühlt sich das an wie das Öffnen einer Schublade: kurz hineinlangen, ein paar Werkzeuge herausnehmen, fertig.

Tatsächlich ist es aber eher so, als würden Sie eine Tür öffnen und fremden Handwerkern erlauben, in Ihrem Haus alles zu tun, was sie für nötig halten, Wände aufstemmen inklusive.

npm install ist kein passiver Schritt

Aus technischer Sicht startet npm install automatisch eine Reihe von Skripten. Diese Skripte laufen mit denselben Rechten wie Sie selbst. Sie dürfen Dateien lesen, Netzwerkverbindungen aufbauen und Programme starten.

In der Fachsprache heißt das Remote Code Execution, also "Code-Ausführung aus der Ferne". Klingt dramatisch, ist es auch.

Ein Vergleich aus dem Alltag

Denken Sie an ein Kochrezept aus dem Internet. Normalerweise lesen Sie es und entscheiden selbst, welche Schritte Sie ausführen. Bei npm ist es so, als würden Sie das Rezept herunterladen und es kocht sich von selbst, inklusive Einkauf, Schneiden, Braten.

Wenn jetzt jemand das Rezept manipuliert hat und dort plötzlich steht "Öffne nebenbei kurz die Haustür für Fremde", dann passiert genau das, ohne dass Sie es bemerken.

Lifecycle-Skripte: Die kleinen Helfer, die zur Waffe werden

Damit npm überhaupt nützlich ist, gibt es sogenannte Lifecycle-Skripte. Das sind kleine Helferlein, die automatisch zu bestimmten Zeitpunkten der Installation ausgeführt werden. Eigentlich eine gute Idee, aber eben auch eine offene Tür.

Die drei wichtigsten Phasen

Es gibt drei Phasen, die Sie kennen sollten. In der preinstall-Phase wird die Umgebung vorbereitet. Angreifer mögen diese Phase besonders, weil hier Sicherheits-Scanner noch nicht gegriffen haben.

Die install-Phase erledigt die eigentliche Einrichtung des Pakets. Und in der postinstall-Phase wird aufgeräumt, oder eben Daten verschickt und Schadcode nachgeladen.

Wie aus Helfern Angriffswerkzeuge werden

Stellen Sie sich Lifecycle-Skripte wie einen Hauswart vor, der vor dem Einzug schon die Schlüssel umdreht, die Heizung aufdreht und Strom anschließt. Praktisch!

Aber wenn ein falscher Hauswart kommt, kann er stattdessen die Schlösser austauschen, eine Kamera einbauen und den Briefkasten umleiten. Genau das ist die Gefahr, die in diesen Skripten steckt.

Fallstudie 1: Der qix-Vorfall und die geknackte Identität

Im September 2025 wurde der Fall "qix" zu einem Lehrbeispiel. Angreifer schickten einem bekannten Maintainer, also einem Entwickler, der ein populäres Paket pflegt, eine täuschend echte E-Mail. Die Adresse support@npmjs.help sah offiziell aus, war aber gefälscht.

Wenn Vertrauen zur Schwachstelle wird

Der Maintainer fiel auf die Phishing-Mail herein und gab seine Zugangsdaten preis. Damit hatten die Angreifer freie Hand.

Sie veröffentlichten manipulierte Versionen weit verbreiteter Pakete wie debug@4.4.2 und chalk@5.6.1.

Diese Pakete sind so beliebt, dass sie indirekt in Millionen von Projekten landen.

Warum klassische Prüfungen versagten

Das Perfide: Die Pakete waren technisch korrekt signiert, schließlich kamen sie vom "echten" Account. Es ist, als würde ein Einbrecher Ihren Hausschlüssel benutzen. Die Tür meldet keinen Alarm, weil sie den Schlüssel kennt.

Die Schadsoftware zielte gezielt auf Browser, die mit MetaMask-Wallets arbeiten, und manipulierte Krypto-Transaktionen, Geld floss direkt in die Taschen der Angreifer.

Fallstudie 2: Shai-Hulud, der digitale Wurm

Wenn der qix-Fall ein gezielter Einbruch war, dann ist Shai-Hulud eine Heuschreckenplage. Diese Schadsoftware tauchte erstmals zwischen September und November 2025 auf und legte ein bisher unbekanntes Tempo vor.

So funktioniert die Selbstvermehrung

Shai-Hulud sucht nach Anmeldedaten in der Entwicklungsumgebung, etwa npm-Tokens, GitHub-Zugriffsschlüssel oder Zugangsdaten zu AWS, Google Cloud und Azure.

Hat der Wurm einmal Beute gemacht, lädt er die gestohlenen Daten in öffentliche Repositories anderer Opfer hoch. Das verwirrt nicht nur die Ermittler, sondern verbreitet die Infektion gleichzeitig weiter.

Der eingebaute Selbstzerstörungsmodus

Besonders gemein ist eine Art "Totmannschalter" in der zweiten Version: Wenn die Schadsoftware merkt, dass sie nichts klauen kann, löscht sie aus Rache lokale Dateien des Opfers.

Moderne Malware spioniert also nicht nur, sie zerstört notfalls auch. Technisch nutzt sie zur Tarnung die Bun-Runtime und einen über zehn Megabyte großen, verschleierten Code, schwer zu analysieren, leicht zu unterschätzen.

Die neue Front: Angriffe auf Build-Server und Pipelines

Lange Zeit war der Computer des Entwicklers das Hauptziel. Heute sind es die CI/CD-Pipelines, also die automatisierten Bauanlagen, in denen Software gebaut und veröffentlicht wird.

Der Nx-Vorfall: Wenn Pull-Requests gefährlich werden

Im August 2025 zeigte der Fall Nx, wie schnell ein Detail zum Sicherheitsrisiko wird. Über unsaubere Pull-Request-Titel und eine riskante Konfiguration namens pull_request_target konnte ungeprüfter Code aus Forks Zugriff auf geheime Daten erhalten.

Das ist, als würde der Pförtner einer Firma jedem Boten die Geheimakte aushändigen, nur weil der Lieferschein lustig formuliert ist.

Der TanStack-Vorfall und das Märchen vom sicheren Token

Im Mai 2026 traf es das TanStack-Projekt. Hier galt eigentlich der moderne Sicherheitsstandard OIDC (Trusted Publishing) als Schutz. Die Idee dahinter: Statt langlebiger Passwörter werden kurzlebige Tokens verwendet.

Die Angreifer fanden trotzdem einen Weg. Sie lasen das Token während der Laufzeit direkt aus dem Arbeitsspeicher des Build-Servers aus. In nur sechs Minuten veröffentlichten sie 84 manipulierte Versionen über 42 Pakete.

Was uns das lehrt

OIDC ist ein nützliches Werkzeug, aber kein Allheilmittel. Wenn der Build-Server kompromittiert ist, hilft auch das kurzlebigste Token nichts mehr. Sicherheit ist eine Kette, und die ist immer nur so stark wie ihr schwächstes Glied.

Die Lösung: Zero-Trust statt blindes Vertrauen

Der Kern aller Schutzmaßnahmen lässt sich in einem Satz zusammenfassen: Vertrauen Sie nichts, was Sie nicht überprüft haben. Das klingt paranoid, ist aber die einzige Haltung, die heute noch funktioniert.

Eine praktische Checkliste für Ihren Alltag

Setzen Sie als Erstes konsequent npm install --ignore-scripts ein. Damit verhindern Sie, dass Lifecycle-Skripte automatisch loslegen.

Entfernen Sie zweitens die Zeichen ^ und ~ aus Ihrer package.json und nutzen Sie exakte Versionsnummern. So bekommen Sie nicht plötzlich eine manipulierte Version untergeschoben.

Netzwerk im Blick behalten

Überwachen Sie drittens, wohin Ihr Build-Server während der Installation Verbindungen aufbaut. Blockieren Sie alles, was nicht ausdrücklich erlaubt ist.

Prüfen Sie viertens die Herkunftsnachweise (Attestations) der Pakete, das digitale Pendant zum Echtheitszertifikat.

Und nutzen Sie fünftens für jeden Build frische, kurzlebige Build-Umgebungen, die nach dem Job sofort verschwinden.

Warum das so wichtig ist

Sehen Sie es so: Wenn jeder Lieferant nur ein einziges Mal Ihre Wohnung betreten darf und dann der Schlüssel sofort neu programmiert wird, hat ein Einbrecher kaum eine Chance. Genau dieses Prinzip übertragen Sie damit auf Ihre Build-Infrastruktur.

Fazit: Wachsamkeit ist die neue Standardeinstellung

Die gute Nachricht zuerst: Sie müssen kein Sicherheits-Profi werden, um Ihre Projekte deutlich besser zu schützen. Sie müssen nur verstehen, dass npm install kein harmloser Aufruf ist, sondern eine bewusste Vertrauensentscheidung. Die Vorfälle qix, Shai-Hulud, Nx und TanStack zeigen, wie kreativ und schnell Angreifer heute arbeiten.

Die schlechte Nachricht: Es wird nicht weniger werden. Die Lösung liegt nicht in einem einzelnen Werkzeug, sondern in einer veränderten Haltung. Wer Abhängigkeiten als das behandelt, was sie sind, nämlich fremder Code mit voller Ausführungsmacht, hat schon den wichtigsten Schritt getan.

Setzen Sie heute an, prüfen Sie ein Projekt nach dem anderen und gewöhnen Sie sich an die kleinen Sicherheitsroutinen. Ihre zukünftigen Anwendungen, Kunden und Daten werden es Ihnen danken.

Häufig gestellte Fragen

Muss ich jetzt alle meine Projekte sofort umstellen?

Nein, aber Sie sollten zügig anfangen. Beginnen Sie mit dem Projekt, das die wichtigsten Daten verarbeitet oder den größten Schaden anrichten kann, wenn es kompromittiert wird.

Setzen Sie dort zuerst exakte Versionsnummern und schalten Sie Lifecycle-Skripte ab. Arbeiten Sie sich dann nach und nach durch Ihre weiteren Projekte. Schritt für Schritt ist besser als gar nicht.

Ist --ignore-scripts nicht ein Risiko, weil dann nichts mehr richtig installiert wird?

Manche Pakete brauchen tatsächlich ihre Lifecycle-Skripte, zum Beispiel um native Bestandteile zu kompilieren. In so einem Fall sollten Sie das gezielt und kontrolliert in einer isolierten Umgebung erlauben, etwa in einem Container.

Generell gilt aber: Die meisten Projekte funktionieren auch ohne Skripte problemlos. Probieren Sie es einfach aus und beobachten Sie, was passiert.

Was mache ich, wenn ich vermute, dass ich bereits ein manipuliertes Paket installiert habe?

Trennen Sie zuerst den betroffenen Rechner vom Netzwerk, um eine mögliche Datenabfluss-Verbindung zu kappen. Ändern Sie anschließend alle Zugangsdaten, die der Rechner kannte, npm-Tokens, GitHub-Schlüssel, Cloud-Zugänge.

Schauen Sie sich Ihre package-lock.json an und vergleichen Sie die Versionen mit aktuellen Sicherheitsmeldungen.

Im Zweifel lohnt es sich, das betroffene System komplett neu aufzusetzen, statt zu hoffen, dass "schon nichts passiert" ist.