Deine Website ist ein kompromittiertes npm-Paket vom Desaster entfernt

Im März 2026 hat eine nordkoreanische Hackergruppe eine Version von axios mit Hintertür auf npm veröffentlicht. Axios hat 100 Millionen wöchentliche Downloads. Die Chance ist groß, dass es gerade in deiner Website steckt.

Wenn ich ein Next.js-Projekt für einen Kunden baue, installiere ich vielleicht 5 bis 10 Pakete, die ich bewusst ausgewählt habe. Aber npm installiert insgesamt über 300 Pakete. Den Quellcode von wie vielen davon habe ich gelesen? Von ungefähr null.

Niemand liest die Pakete. Niemand hat die Zeit. Und genau darauf setzen die Angreifer.

Was genau mit Axios passiert ist

Am 30. März 2026, um 23:59 UTC, hat jemand den npm-Account des Axios-Maintainers jasonsaayman gekapert. Sie haben die E-Mail auf eine Proton-Adresse geändert und 21 Minuten später axios v 1.14.1 mit dem Tag latest veröffentlicht.

Die Angreifer haben keinen bestehenden Code kaputtgemacht. Sie haben keine offensichtliche Malware hinzugefügt. Sie haben eine neue Dependency eingeschmuggelt: plain-crypto-js. Deren postinstall Hook hat im Hintergrund einen Remote Access Trojaner auf Windows, macOS und Linux Rechner heruntergeladen. PowerShell auf Windows. Ein C++ Daemon auf macOS. Ein Python-Script auf Linux. Plattformübergreifend, gründlich, professionell.

Microsoft hat den Angriff Sapphire Sleet zugeordnet, einem nordkoreanischen staatlichen Akteur. Kein Script-Kiddie. Eine staatlich finanzierte Hacker-Operation, die auf die JavaScript Supply Chain abzielt.

Das kompromittierte Zeitfenster war ungefähr 4 Stunden. In diesen 4 Stunden bekam jeder, der npm install in einem Projekt mit axios ausgeführt hat, einen RAT auf seinen Rechner. Oder schlimmer: auf seinen CI/CD-Server, der typischerweise Zugriff auf Datenbank-Credentials, API-Keys und Deployment-Tokens hat.

Der Fix war einfach: Zurückrollen auf axios v 1.14.0. Aber wie viele Leute haben das rechtzeitig bemerkt? Und wie viele CI/CD-Pipelines liefen automatisch in diesem Zeitfenster?

Das ist kein Einzelfall. Das ist die neue Normalität.

Wenn du denkst, das war einmalig, sagen die Zahlen etwas anderes.

Bösartige npm-Pakete stiegen von 38 im Jahr 2018 auf 2.168 im Jahr 2024 auf 454.648 im Jahr 2025. Das ist kein Tippfehler. Vierhundertvierundfünfzigtausend bösartige Pakete, die in einem einzigen Jahr auf npm veröffentlicht wurden. Allein in Q4 2025 blockierte Sonatype über 120.000 Malware-Angriffe. 99,8% aller Open-Source-Malware stammte spezifisch aus npm.

Im September 2025 passierte etwas noch Beängstigenderes. Der Shai-Hulud-Wurm wurde der erste sich selbst replizierende npm-Wurm. Er verbreitete sich autonom über 500+ Pakete und trojanisierte zeitweise Projekte von Zapier, PostHog, Postman und ENS Domains. Ein separater Phishing-Angriff im selben Monat kompromittierte chalk, debug, ansi-styles und strip-ansi, Pakete mit zusammen 2,6 Milliarden wöchentlichen Downloads. Lass das mal sacken.

Ich habe über die Sicherheitsprobleme geschrieben, die mit AI-generiertem Code kommen. Der Supply-Chain-Winkel ist dasselbe grundlegende Problem: Wir vertrauen Code, den wir nicht geschrieben haben und oft nicht verifizieren können.

Das eigentliche Problem: Du verwendest Code, den du nie gelesen hast

Hier ist ein Experiment. Erstelle jetzt gerade eine frische Next.js App. Führe create-next-app aus. Schau in deine package.json. Du wirst vielleicht 5 bis 10 explizite Dependencies sehen. Macht Sinn.

Jetzt schau in deinen node_modules Ordner. Über 300 Pakete. Jedes einzelne kann beliebigen Code auf deinem Rechner ausführen, sobald du npm install laufen lässt. Keine Rückfragen. Keine Bestätigung. Kein Audit. Einfach blindes Vertrauen.

Stell dir das so vor: Du hast einen Bauunternehmer engagiert, um dein Haus zu bauen. Der hat 200 andere Leute als Subunternehmer geholt. Du hast keinen von ihnen getroffen. Du kennst ihre Namen nicht. Du kennst ihre Qualifikationen nicht. Aber sie alle haben Schlüssel zu deiner Haustür.

Das macht npm install. Jedes Mal.

Das Ökosystem basiert auf Vertrauensketten, die lautlos brechen. npms Design bedeutet, dass jedes Paket bei der Installation Code auf deinem Rechner ausführen kann, mit deinen Berechtigungen. Und wenn etwas schiefgeht, gibt es keinen Alarm. Keine Benachrichtigung. Nur ein Trojaner, der leise im Hintergrund läuft.

Ich habe darüber geschrieben, wie Claude großartig darin ist, Software zu bauen, und genauso großartig darin, sie kaputtzumachen. AI-unterstützte Entwicklung macht dieses Problem schlimmer, nicht besser. Vibe-gecodete Projekte neigen dazu, mehr Dependencies zu haben, weil es schneller geht, ein Paket zu installieren als die Funktionalität selbst zu schreiben. Mehr Dependencies bedeutet mehr Angriffsfläche, die niemand auditiert.

Warum kleine Websites härter getroffen werden als große Unternehmen

Große Unternehmen haben Security Operations Center. Sie haben Software Bill of Materials Tooling. Vulnerability Scanner, die rund um die Uhr laufen. Dedizierte Sicherheitsteams, deren einziger Job es ist, genau auf solche Dinge zu achten.

Eine One-Person-Agentur hat nichts davon. Ein 3-Personen-Startup auch nicht. Der lokale Klempner, dessen Website du letzten Monat gebaut hast, auch nicht.

Der Blast Radius ist auch anders. Wenn ein RAT auf einem CI/CD-Server landet, der die Datenbank-Credentials deines Kunden hält, seine Stripe API-Keys, seine E-Mail-Service-Tokens, alles als Umgebungsvariablen gespeichert, ist das kein theoretisches Risiko. Das sind die Kundendaten deines Kunden, die zur Tür rausspazieren.

Wiz fand heraus, dass die Axios-Malware in etwa 3% der betroffenen Umgebungen ausgeführt wurde. Drei Prozent von 100 Millionen wöchentlichen Downloads. Das sind 3 Millionen Ausführungen.

Kleine Unternehmen deployen von persönlichen Laptops. Sie speichern Secrets als einfache .env-Dateien. Sie laufen auf Shared Hosting. Sie haben keinen Incident Response Plan. Und sie haben keine Möglichkeit zu wissen, ob sie betroffen waren.

Das ist dasselbe Muster, das ich sehe, wenn SaaS-Stacks Unternehmen ausnehmen: Wir nutzen Software von Fremden, und wenn etwas schiefgeht, gibt es keinen Support, den man anrufen kann.

Fünf Dinge, die du tatsächlich tun kannst (die keine Enterprise-SBOM-Tools sind)

Ich werde dir nicht sagen, dass du eine vollständige Software Bill of Materials Pipeline implementieren sollst. Du bist Freelancer. Du hast keine Zeit dafür. Hier sind fünf Dinge, die tatsächlich für einen Solo-Entwickler oder ein kleines Team funktionieren.

1. Nutze npm ci in deiner Deploy-Pipeline, nicht npm install. Das ist die einzelne größte Änderung, die du machen kannst. npm ci installiert exakt aus dem Lockfile. npm install kann Pakete still auf neuere Versionen upgraden, was genau der Weg war, über den sich der Axios-Angriff verbreitet hat. Eine Zeile Config in deinem Build-Step. Riesiger Unterschied.

2. Committe dein Lockfile und update es nie automatisch. Deine package-lock.json oder yarn.lock pinnt exakte Versionen. Behandle jeden automatisierten PR, der Dependencies bumpt, als etwas, das einen menschlichen Review braucht. Nicht nur einen Merge-Klick. Einen tatsächlichen Blick darauf, was sich geändert hat und warum.

3. Füge Socket zu deinem GitHub hinzu. Socket.dev ist kostenlos für Open Source und günstig für kleine Teams. Es scannt Pull Requests in Echtzeit auf Supply-Chain-Bedrohungen. Dauert zwei Minuten zu installieren. Das ist das einzige Enterprise-Grade-Tool, das tatsächlich auf einen Solo-Entwickler runterskaliert.

4. Installiere mit --ignore-scripts wo möglich. npm install --ignore-scripts verhindert, dass postinstall Hooks ausgeführt werden. Postinstall Hooks waren der Angriffsvektor bei der Axios-Kompromittierung, dem Shai-Hulud-Wurm und dem Chalk-Angriff. Die meisten Pakete brauchen sie nicht. Die bösartigen immer.

5. Warte, bevor du auf eine neue Major-Version upgradest. Die meisten npm Supply-Chain-Angriffe werden innerhalb von Stunden oder Tagen entdeckt und entfernt. Eine simple 7-Tage-Verzögerungspolitik beim Upgrade auf neue Releases hätte das gesamte Axios-Angriffsfenster komplett geblockt. Du musst nicht auf dem Bleeding Edge sein. Lass andere zuerst die Minen finden.

Ich habe über das Reparieren meiner Next.js Build-Pipeline geschrieben. Build-Pipelines verdienen Aufmerksamkeit, nicht nur für Performance, sondern auch für Sicherheit. Wenn dein Deploy npm install statt npm ci ausführt, würfelst du jedes Mal, wenn du pushst.

Ich habe meine eigenen Projekte geprüft. Du solltest deins auch prüfen.

Nachdem die Axios-Nachricht rausgekommen ist, habe ich meine eigenen Projekte geprüft. Ich habe die kompromittierte Version nicht verwendet. Aber ich hatte Pakete mit über 200 transitiven Dependencies, und ich hatte genau keine davon auditiert.

Ich habe Socket an dem Nachmittag zu meinem GitHub hinzugefügt. Ich habe meine Deploy-Scripts auf npm ci umgestellt. Ich habe angefangen, --ignore-scripts für lokale Installationen zu verwenden. Hat insgesamt etwa 30 Minuten gedauert.

Es gibt keine Wunderwaffe. Du kannst alle fünf Dinge oben machen und trotzdem von einem Zero-Day getroffen werden. Das Ziel ist nicht perfekte Sicherheit. Das Ziel ist, die Kosten eines Angriffs auf dich zu erhöhen und den Blast Radius zu reduzieren, wenn etwas durchkommt.

Ich bin kein Sicherheitsforscher. Aber ich shippe Websites mit über 300 Paketen darin, und du auch. Das Mindeste, was wir tun können, ist aufzuhören so zu tun, als wäre die Supply Chain das Problem von jemand anderem.

Wenn du ein zweites Paar Augen auf deinem Stack willst, bevor du shippst, oder dich fragst, was sonst noch in deinen node_modules lauert, genau so etwas mache ich bei wunderlandmedia.de. Keine Panikmache. Einfach ein ehrlicher Blick darauf, was tatsächlich auf deinem Server läuft.