npm ist kaputt. Und du weißt es nur noch nicht.

Heute Nacht, während du geschlafen hast, wurde Axios kompromittiert. Falls dir der Name nichts sagt: Axios ist die HTTP-Bibliothek, die in fast jeder JavaScript-Anwendung steckt die du je gebaut oder genutzt hast. Hundert Millionen Downloads pro Woche. Millionen von Projekten weltweit. Und seit heute Nacht enthielt die neueste Version einen Remote Access Trojan der Angreifer vollständige Kontrolle über Entwicklermaschinen gibt — unter Windows, macOS und Linux.

Das ist kein theoretisches Sicherheitsproblem. Das ist heute. Jetzt. Und es ist nur der aktuellste Akt in einem Stück, das seit Monaten eskaliert.

Was gerade mit npm passiert, ist kein Zufall

Malicious Packages im npm-Ökosystem sind kein neues Phänomen. 2018 wurden 38 bösartige Pakete gemeldet. 2024 waren es über 2.000. Snyk identifizierte allein in 2024 mehr als 3.000 schädliche npm-Pakete. Im letzten Quartal 2025 blockierte Sonatype über 120.000 Malware-Angriffe — in drei Monaten.

Das ist kein gradueller Anstieg mehr. Das ist eine Industrie.

Die Angreifer haben verstanden, was Entwickler oft verdrängen: Du installierst nie nur ein Paket. Wenn du npm install axios tippst, landet nicht axios auf deinem System — sondern axios plus alle seine Abhängigkeiten, plus die Abhängigkeiten dieser Abhängigkeiten. Ein modernes JavaScript-Projekt hat schnell über tausend Pakete, die von Hunderten verschiedener Maintainer gepflegt werden. Du vertraust ihnen allen. Blind.

Eingebetteter Schadcode macht mittlerweile fast die Hälfte aller npm-Schwachstellen aus. Das sind keine Programmierfehler, keine schlecht getesteten Edge Cases. Das sind Pakete die mit böser Absicht veröffentlicht wurden.

Wie ein einzelnes Phishing-Mail Milliarden Downloads vergiftet

Am 8. September 2025 ging eine E-Mail an Josh Junon raus. Absender: support@npmjs.help. Inhalt: dein Account wird in 48 Stunden gesperrt. Der Mann hatte eine stressige Woche, einen langen Morgen, wollte eine Sache von seiner To-Do-Liste streichen. Er klickte. Er gab seine Credentials ein.

Josh Junon ist Maintainer von chalk, debug, ansi-styles, strip-ansi und einem Dutzend weiterer Bibliotheken die zusammen über 2,6 Milliarden Downloads pro Woche haben. Du hast sie alle in deinen Projekten. Jeder hat sie.

Die Angreifer veröffentlichten innerhalb von Minuten vergiftete Versionen dieser Pakete. Der injizierte Code war elegant und bösartig zugleich: er wickelte sich um Browser-APIs und schrieb Krypto-Wallet-Transaktionen kurz vor der Signierung um. Geld verschwand lautlos in die Wallets der Angreifer. Keine Fehlermeldung, kein sichtbares Zeichen, kein Alarm.

Die kompromittierten Versionen waren zwei Stunden live. Zwei Stunden bei 2,6 Milliarden wöchentlichen Downloads ist keine kurze Zeit. Vercel, das bei diesen Paketen besonders exponiert war, identifizierte betroffene Projekte und purgte Build-Caches — und das war nur möglich weil ihre Security-Teams sofort reagierten.

Was zunächst nach einem Angriff auf 18 Pakete aussah, wuchs. Am Ende standen über 200 bestätigte kompromittierte Pakete.

Dann kam der Wurm

Was im September 2025 noch wie ein einmaliger Angriff wirkte, war der Startschuss für etwas Neues.

Wenige Tage später tauchte auf dem npm-Registry etwas auf das Security-Forscher "Shai-Hulud" nannten — nach dem Sandwurm aus Dune, und die Namensgebung war treffend. Zum ersten Mal in der Geschichte des npm-Ökosystems hatte ein Angreifer Malware gebaut, die sich selbst verbreitete.

Der Mechanismus war erschreckend einfach: Ein Maintainer-Account wurde kompromittiert, das infizierte Paket wurde installiert, und Shai-Hulud scannte sofort nach npm-Tokens auf dem System. Mit diesen Tokens authentifizierte sich die Malware als der kompromittierte Entwickler, injizierte sich in alle anderen Pakete die dieser Maintainer betreute, und veröffentlichte vergiftete Versionen — die dann beim nächsten Entwickler denselben Zyklus starteten. Automatisch. Ohne weiteres menschliches Zutun.

Über 500 Pakete wurden kompromittiert bevor der Angriff eingedämmt wurde. CISA gab eine offizielle Sicherheitswarnung heraus. GitHub entfernte Pakete notfallmäßig aus dem Registry.

Im November 2025 kam Shai-Hulud 2.0. Aggressiver, breiter, bösartiger. Die neue Version lief nicht mehr im Post-Install, sondern im Pre-Install — was bedeutete dass sie Schaden anrichtete bevor der Package-Manager überhaupt fertig war. Das Scope-Upgrade war dramatisch: über 25.000 bösartige Repositories, über 848 kompromittierte Pakete, und ein neu hinzugefügter Mechanismus der bei Misserfolg das komplette Home-Verzeichnis des Nutzers löschte. Ein digitaler toter Mann als Druckmittel gegen Sicherheitsforscher. CISA war wieder aktiv. Die Community war wieder in Panik.

Heute: Axios

Und dann ist da heute.

Axios ist nicht irgendein Utility-Package. Axios ist die HTTP-Bibliothek. Sie steckt in Frontend-Apps, Backend-Services, CI/CD-Pipelines, Enterprise-Anwendungen, Millionen von privaten und professionellen Projekten. 100 Millionen Downloads pro Woche. Einer der Top-10-npm-Packages überhaupt.

Heute Nacht, konkret am 30. März 2026 kurz vor Mitternacht UTC, wurde ein Paket namens plain-crypto-js@4.2.1 auf npm veröffentlicht. Es sieht aus wie eine legitime Crypto-Bibliothek — gleiche Beschreibung wie crypto-js, gleiche Autorzuweisung, gleiche Repository-URL. Fake. Alles fake.

18 Stunden später, um 00:21 UTC des 31. März, erschien axios@1.14.1 auf dem Registry. Veröffentlicht über den kompromittierten Account des Lead-Maintainers jasonsaayman. Die E-Mail des Accounts wurde auf eine ProtonMail-Adresse geändert. Der Release wurde nicht über GitHub Actions gepusht — das Projekt nutzt eigentlich OIDC Trusted Publishing, was cryptographisch an einen verifizierten Workflow gebunden ist und nicht gestohlen werden kann. Stattdessen wurde ein alter, langlebiger Classic Token genutzt. 39 Minuten später erschien axios@0.30.4 — beide Release-Branches gleichzeitig getroffen, maximale Exposition.

In axios selbst steht keine einzige Zeile Schadcode. Das ist das Geniale und das Erschreckende daran. Stattdessen wurde plain-crypto-js@4.2.1 als neue Dependency injiziert — ein Paket das Axios vorher nie brauchte, nie importiert, nie referenziert hat. Sein einziger Zweck: ein Postinstall-Script ausführen das einen plattformspezifischen Remote Access Trojan dropped, den C2-Server sfrclak[.]com kontaktiert, Payloads für macOS, Windows und Linux lädt — und sich dann selbst löscht und durch eine saubere package.json ersetzt. Wer danach in seine node_modules schaut, sieht nichts.

Socket hat das Schadpaket sechs Minuten nach Veröffentlichung automatisch geflaggt. Nicht npm. Nicht GitHub. Nicht Anthropic. Ein Third-Party-Security-Tool.

Wer axios mit einem Caret-Range installiert hat — also ^1.14.0 oder ^0.30.0, was fast jeder tut — hat beim nächsten npm install automatisch die vergiftete Version gezogen.

Was das über npm aussagt

Es gibt einen Satz aus dem StepSecurity-Report der heute erschienen ist, der alles auf den Punkt bringt: Das ist "einer der operativ ausgefeiltesten Supply-Chain-Angriffe die je gegen ein Top-10-npm-Paket dokumentiert wurden."

Das Angriffsmuster war 18 Stunden im Voraus vorbereitet. Drei separate Payloads für drei Betriebssysteme wurden vorab gebaut. Die Malware löscht sich nach Ausführung selbst. Der Angreifer nutzte ProtonMail-Adressen konsequent über alle verwendeten Accounts hinweg — ein einheitliches, professionelles operatives Muster.

Das ist keine Skript-Kiddie-Aktion. Das sind Profis.

Und das eigentliche Problem sitzt tiefer: npm hat einen fundamentalen Single-Point-of-Failure. Ein Maintainer-Account. Ein gestohlener Token. Ein Phishing-Mail an einem stressigen Morgen. Das reicht, um Milliarden von Downloads zu vergiften — weil das gesamte Ökosystem auf Vertrauen basiert das strukturell nicht abgesichert ist.

npm hat nach Shai-Hulud reagiert und Classic Tokens abgeschafft. Beim Axios-Angriff heute wurde genau so ein Token genutzt — was zeigt dass das Rollout noch Lücken hat und dass Legacy-Credentials länger im Umlauf bleiben als geplant.

Helfen Alternativen wie Bun oder pnpm?

Die ehrliche Antwort: ein bisschen. Aber sie lösen das eigentliche Problem nicht.

pnpm ist gerade der Liebling der Security-Community und das aus gutem Grund. Seit November 2025 gibt es eine Trust-Policy-Funktion: Pakete die plötzlich ohne CI/CD-Provenance veröffentlicht werden — also genau das was beim Axios-Angriff passiert ist — werden als Trust-Downgrade markiert und können geblockt werden. Das wäre heute ein echter Schutz gewesen. Zusätzlich laufen Lifecycle-Scripts in pnpm nicht standardmäßig, was den Angriffsvektor der meisten Malware-Pakete direkt kappt.

Bun hat einen vernünftigen Sicherheitsstandard: Lifecycle-Scripts werden standardmäßig geblockt. Aber mit einer Allow-List für die Top-500-npm-Packages. Axios ist in dieser Liste. Der heutige Angriff hätte also auch unter Bun funktioniert. Dazu kommt ein praktisches Problem: Dependabot unterstützt Buns Lockfile-Format noch nicht ausreichend um Dependency-Graphen oder automatische Sicherheitswarnungen zu liefern. Wer auf GitHub-native Security-Tooling angewiesen ist, hat mit Bun derzeit blinde Flecken.

Deno ist von den dreien am konsequentesten in seinem Sicherheitsmodell — kein automatischer Zugriff auf Filesystem, Netzwerk oder Umgebungsvariablen ohne explizite Permissions. Für neue Projekte ist Deno 2 interessant. Für bestehende npm-Projekte ist der Migrationspfad allerdings realistisch gesehen aufwendig.

Was alle drei verbindet: Sie installieren alle aus demselben npm-Registry. Das vergiftete Axios lädt sich auch mit Bun, pnpm oder Deno herunter. Der Package-Manager ist nicht das Problem. Die Registry ist das Problem. Und die Maintainer-Accounts dahinter.

Im Januar 2026 wurden PackageGate-Bugs in npm, pnpm, vlt und Bun gefunden — also Sicherheitslücken in den Package-Managern selbst die Angreifern erlauben Schutzmaßnahmen zu umgehen. npm hat den Report geschlossen mit dem Hinweis, Nutzer müssten Pakete selbst prüfen. pnpm, vlt und Bun haben die Bugs innerhalb weniger Wochen gefixed.

Was du jetzt tun kannst

Wenn du heute npm install laufst oder in letzter Zeit axios aktualisiert hast: prüf deine package-lock.json auf die Versionen axios@1.14.1 oder axios@0.30.4. Falls eine davon auftaucht, geh davon aus dass das System kompromittiert ist. Downgraden auf 1.14.0 bzw. 0.30.3, plain-crypto-js aus node_modules entfernen, alle Credentials rotieren die auf dem System lagen oder durch Prozesse liefen die in diesem Zeitfenster aktiv waren. CI/CD-Logs des letzten Tages prüfen.

Für alles darüber hinaus: npm ci --ignore-scripts in deiner CI/CD ist eine der wirkungsvollsten Maßnahmen die kaum jemand aktiviert hat. Lifecycle-Scripts sind der beliebteste Angriffsvektor der letzten sechs Monate. Du brauchst sie in den meisten Build-Pipelines nicht.

Lockfile pinnen statt Caret-Ranges (^) vertrauen ist eine einfache Gewohnheit die viel verhindert. ^1.14.0 bedeutet "irgendwas das kompatibel ist" — und das haben Angreifer heute ausgenutzt.

Socket.dev ist das Tool das heute Axios in sechs Minuten geflaggt hat, während npm selbst schwieg. Es gibt eine kostenlose Tier, eine VS Code Extension und eine GitHub App. Für Vibe Coder und Solo-Projekte ist das Preis-Leistungs-Verhältnis schwer zu schlagen.

Zwei-Faktor-Authentifizierung auf deinem npm-Account ist keine Option. Falls du dort noch kein TOTP oder besser einen Hardware-Key aktiv hast: heute ist ein guter Tag. npm hat Ende 2025 angekündigt 2FA bei neuen Paketen standardmäßig zu aktivieren — aber für bestehende Accounts liegt es bei dir.

Was das für die Zukunft bedeutet

Veracode hat am Ende 2025 etwas festgestellt das ich nicht ignorieren kann: In manchen analysierten Schadpaketen fanden sich Kommentare die emoji-reich waren und stylistische Muster zeigten die auf LLM-Nutzung hindeuten. Vibe Coding als Angriffsvektor. Angreifer die KI nutzen um schneller, mehr und schwerer erkennbare Malware zu produzieren.

Der Sicherheitsforscher aus dem Veracode-Report schrieb dazu: Das Vorhandensein dieser Würmer ist klarer Beweis der Kraft automatisierter Kompromittierung. Wir werden das 2026 deutlich mehr sehen.

Die Attacken sind persistent, automatisiert und industrialisiert. Das ist kein Trend der wieder abklingt. Das npm-Ökosystem hat strukturelle Probleme die kurzfristig nicht lösbar sind — weil sie auf dem Vertrauen in einzelne Maintainer basieren, und Menschen immer phishbar bleiben.

Was das für Vibe Coder konkret bedeutet: Du bist nicht nur ein Entwickler mehr. Du bist auch ein Sicherheitsverantwortlicher. Nicht weil du Penetration-Testing können musst — sondern weil du für die Codebasis verantwortlich bist die du deinen Kunden auslieferst. Ein kompromittiertes Build das deinen Kunden-Server trifft ist nicht das Problem von npm. Es ist deins.

Das ist keine schöne Erkenntnis. Aber sie ist notwendig.