Am 31. März 2026 wurde axios kompromittiert. 100 Millionen wöchentliche Downloads. Zwei Versionen mit einem Remote Access Trojan infiziert. Die Schadversionen waren rund 4,5 Stunden auf npm verfügbar — und wer in diesem Fenster npm install ausführte, hatte einen Trojaner auf dem Rechner.
Wir bei Evelan haben an diesem Tag nicht nur unsere Repositories geprüft. Wir haben einen Claude Code Hook gebaut, der so etwas in Zukunft automatisch verhindert. Wie der funktioniert, warum wir ihn brauchen und wie ihr ihn in 10 Minuten einrichten könnt: das ist dieser Artikel.
Key Takeaways
- npm ist die Hauptquelle für Open-Source-Malware: 99,8 % aller Schadpakete in Q4 2025 kamen aus dem npm-Ökosystem (Sonatype, 2025).
- Exakte Versionen in der package.json (save-exact=true) schützen vor automatischem Upgrade auf kompromittierte Versionen.
- Ein Claude Code Hook prüft jede Installation gegen die OSV.dev-Datenbank und blockiert bekannte Schwachstellen in Echtzeit.
- Den Hook einzurichten dauert unter 10 Minuten — das Script und die Konfiguration findet ihr in diesem Artikel.
Was ist bei der axios npm Supply Chain Attack passiert?
Laut Microsoft Threat Intelligence war der Angriff das Werk von Sapphire Sleet, einem nordkoreanischen Bedrohungsakteur (Microsoft Security Blog, 2026). Zwei axios-Versionen wurden mit einem RAT (Remote Access Trojan) infiziert: axios@1.14.1 und axios@0.30.4.
Der Mechanismus war raffiniert. Die kompromittierten Versionen enthielten eine versteckte Dependency namens plain-crypto-js@4.2.1. Dieses Paket führte beim Install ein postinstall-Script aus, das drei Dinge tat:
- Einen Command-and-Control-Server kontaktierte (sfrclak.com:8000)
- Einen plattformspezifischen Payload herunterlud (macOS, Windows, Linux)
- Sich selbst löschte und die package.json bereinigte. Innerhalb von 2 Sekunden.
Die Timeline
| Zeitpunkt (UTC) | Ereignis |
|---|---|
| 30.03., 05:57 | Sauberes Decoy-Paket plain-crypto-js@4.2.0 veröffentlicht |
| 30.03., 23:59 | Schadversion plain-crypto-js@4.2.1 mit RAT-Dropper veröffentlicht |
| 31.03., 00:21 | axios@1.14.1 mit vergifteter Dependency veröffentlicht |
| 31.03., 01:00 | axios@0.30.4 veröffentlicht (39 Min. später) |
| 31.03., ~03:15 | npm entfernt beide axios-Versionen |
| 31.03., 03:25 | npm sperrt plain-crypto-js |
Zeitpunkt (UTC) / Ereignis
- Zeitpunkt (UTC)
- 30.03., 05:57
- Ereignis
- Sauberes Decoy-Paket plain-crypto-js@4.2.0 veröffentlicht
- Zeitpunkt (UTC)
- 30.03., 23:59
- Ereignis
- Schadversion plain-crypto-js@4.2.1 mit RAT-Dropper veröffentlicht
- Zeitpunkt (UTC)
- 31.03., 00:21
- Ereignis
- axios@1.14.1 mit vergifteter Dependency veröffentlicht
- Zeitpunkt (UTC)
- 31.03., 01:00
- Ereignis
- axios@0.30.4 veröffentlicht (39 Min. später)
- Zeitpunkt (UTC)
- 31.03., ~03:15
- Ereignis
- npm entfernt beide axios-Versionen
- Zeitpunkt (UTC)
- 31.03., 03:25
- Ereignis
- npm sperrt plain-crypto-js
Das Tückische: Nach der Installation sah alles normal aus. Die Malware hatte sich selbst aus dem Dateisystem entfernt. Zurück blieb nur der Trojaner, versteckt an einer plattformspezifischen Stelle:
Quelle
Wer die Datei auf seinem System findet, wurde kompromittiert. Keine Fehlermeldung, kein Warning. Einfach ein stiller Trojaner. Mehr dazu in unserem Artikel über die größten Sicherheitslücken moderner Websites.
Warum ist npm das Hauptziel für Supply Chain Attacks?
npm ist nicht zufällig das Hauptziel. In Q4 2025 stammten 99,8 % aller Open-Source-Malware aus dem npm-Ökosystem (Sonatype Q4 2025 Index, 2025). Allein im vierten Quartal 2025 wurden 394.877 neue Schadpakete veröffentlicht, ein Anstieg von 476 % gegenüber den drei Quartalen davor. Warum ausgerechnet npm? Drei Gründe.
Erstens: Volumen. npm verarbeitet den Großteil der 9,8 Billionen jährlichen Open-Source-Downloads (Sonatype 2026 Report, 2026). Mehr Downloads bedeuten mehr potenzielle Opfer. Das macht npm zum lukrativsten Ziel im gesamten Open-Source-Ökosystem.
Zweitens: postinstall-Scripts. npm führt nach der Installation automatisch Scripts aus. Das ist ein Feature, aber gleichzeitig ein Einfallstor. Kein anderes Ökosystem macht das so permissiv.
Drittens: Automatisierung. Die IndonesianFoods-Kampagne hat gezeigt, wie weit das gehen kann. Die Angreifer veröffentlichten 100.000 Schadpakete in wenigen Tagen, alle 7 Sekunden ein neues Paket (Sonatype, 2025). Damit verdoppelten sie kurzzeitig die gesamte Malware auf npm.
Unsere Beobachtung
Der axios-Angriff vom März 2026 ist kein Einzelfall. Wir zählen inzwischen vier große npm-Kompromittierungen in den letzten acht Jahren: event-stream (2018), ua-parser-js (2021), colors.js (2022) und jetzt axios (2026). Die Frequenz nimmt zu, die Angriffe werden ausgefeilter.
Wie wir bei Evelan der Supply Chain Attack entkommen sind
Laut Black Duck enthielten 2026 im Schnitt 581 Schwachstellen pro kommerzieller Codebasis, ein Anstieg von 107 % gegenüber dem Vorjahr (Black Duck OSSRA 2026, 2026). Wir haben uns schon vor längerer Zeit entschieden, grundsätzlich exakte Versionen in unseren package.json-Dateien zu verwenden. Kein ^, kein ~, keine Ranges. Das hat uns geschützt. Aber nicht komplett.
Bei einem Audit unserer über 110 Repositories (90+ auf Bitbucket, 21 auf GitHub) haben wir zwei Altlasten gefunden. Prototypen, die man mal schnell aufgesetzt und dann vergessen hat:
Das Audit selbst hat ca. 10 Minuten gedauert. Claude Code hat parallel zwei Agents losgeschickt, einen für GitHub, einen für Bitbucket. Jedes Repository wurde auf die kompromittierten Versionen und das Schadpaket plain-crypto-js geprüft. Beide Altlasten wurden noch am selben Tag gefixt — unter anderem in unseren Web App Projekten.
Hätte jemand in diesem 4,5-Stunden-Fenster ein npm install in einem dieser Projekte ausgeführt, hätte die Lambda-Funktion mit "axios": "latest" die infizierte Version 1.14.1 gezogen. Unsere Website Sicherheit Checkliste hilft, solche Risiken systematisch zu vermeiden.
So stellt ihr eure Projekte auf exakte Versionen um
65 % aller Organisationen erlebten laut Black Duck im vergangenen Jahr einen Software-Supply-Chain-Angriff (Black Duck OSSRA 2026, 2026). Exakte Versionen sind die einfachste Gegenmaßnahme. Drei Optionen:
Option A: Projektweite .npmrc (empfohlen)
Erstellt eine .npmrc-Datei im Root eures Projekts:
Ab jetzt schreibt jedes npm install <paket> automatisch die exakte Version in die package.json — ohne ^. Das gilt für jeden Entwickler, der in diesem Repository arbeitet. 10 Sekunden Aufwand, dauerhafter Schutz.
Option B: Globale Einstellung
Gilt für alle Projekte auf eurem Rechner. Praktisch als persönliche Absicherung, aber kein Ersatz für die projektweite .npmrc, weil sie nur auf eurer Maschine wirkt.
Option C: Manuell pro Install
Unsere Empfehlung: Option A für jedes Projekt, Option B als persönliches Sicherheitsnetz. Kostet nichts, schützt sofort.
Schutz vor npm Supply Chain Attacks: Der Claude Code Hook
GitHub veröffentlichte 2025 insgesamt 7.197 Malware-Advisories, ein Anstieg von 69 % gegenüber dem Vorjahr (GitHub, 2025). Exakte Versionen schützen vor automatischen Upgrades, aber nicht vor der Installation eines bereits kompromittierten Pakets. Dafür braucht es einen aktiven Check.
Wir gehen einen Schritt weiter: Ein Claude Code Hook prüft bei jedem npm install automatisch, ob für die zu installierende Version bekannte Sicherheitslücken existieren. Wenn ja, blockiert er die Installation. Claude Code ist damit nicht nur ein Code-Generator, sondern wird zum aktiven Security-Werkzeug im Kampf gegen npm Supply Chain Attacks.
So funktioniert der Hook:
Das Hook-Script
Hook-Konfiguration
Speichert das Script als ~/.claude/hooks/npm-safety-check.sh und macht es ausführbar (chmod +x). Dann fügt diese Konfiguration in ~/.claude/settings.json ein:
Der Hook in Aktion — zwei Szenarien
Was passiert, wenn jemand (oder eine KI) versucht, die kompromittierte axios-Version zu installieren?
Szenario 1: Kompromittiertes Paket wird blockiert
Ausgabe:
MAL-2026-2307 ist die OSV-Kennung für den axios-Trojaner. Der Entwickler (oder die KI) bekommt eine klare Meldung und kann eine sichere Version wählen. Kein Durchkommen.
Szenario 2: Sauberes Paket, aber --save-exact fehlt
Ausgabe:
Die package.json bekommt "lodash": "4.17.21" statt "lodash": "^4.17.21". Automatisch, ohne Nachdenken.
Was ist OSV.dev — und warum nutzen wir es?
Die globalen Kosten von Software-Supply-Chain-Angriffen lagen 2025 bei 60 Milliarden US-Dollar. Bis 2031 sollen es 138 Milliarden werden (Cybersecurity Ventures, 2025). Dagegen helfen nur Datenbanken, die Schwachstellen in Echtzeit erfassen.
Der Hook nutzt die OSV.dev API (Open Source Vulnerabilities) — ein offenes Projekt von Google, das Vulnerability-Daten aus mehreren Quellen aggregiert:
- npm Security Advisories: die offiziellen npm-Meldungen
- GitHub Advisory Database (GHSA): die größte kuratierte Advisory-Datenbank
- Snyk Vulnerability Database: ergänzende Vulnerability-Daten
Die API ist kostenlos, braucht keinen API-Key und liefert Ergebnisse für eine spezifische Paket-Version:
Warum nicht npm audit? npm audit prüft die bereits installierten Pakete. Unser Hook prüft vor der Installation. Das ist der Unterschied zwischen Brandmelder und Brandschutztür.
Drei Dinge, die ihr heute noch machen könnt
Der Verizon DBIR 2025 zeigt: 30 % aller Datenlecks involvieren inzwischen einen Drittanbieter. Das ist eine Verdopplung gegenüber dem Vorjahr (Verizon DBIR 2025, 2025). npm Supply Chain Attacks sind kein Randthema mehr. Hier sind drei konkrete Maßnahmen, die ihr heute noch umsetzen könnt:
- .npmrc mit save-exact=true in jedes Projekt. Dauert 10 Sekunden, schützt dauerhaft vor automatischen Upgrades auf kompromittierte Versionen.
- npm audit in eure CI/CD-Pipeline einbauen. Fängt bekannte Vulnerabilities beim Build. Nicht perfekt, aber eine wichtige zusätzliche Schicht.
- Den Claude Code Hook installieren. Wenn ihr mit KI-Assistenten arbeitet, die Pakete installieren, prüft der Hook vor jeder Installation und blockiert bekannte Schwachstellen automatisch.
Was wir gelernt haben
Am 1. April 2026 haben wir alle 110+ Repositories auditiert, Jira-Tickets für die zwei gefundenen Altlasten erstellt, die Teams über Slack benachrichtigt und den Hook gebaut. Alles in einer Claude Code Session, innerhalb eines Vormittags. Das Audit hat 10 Minuten gedauert, der Hook-Bau vielleicht 30. Das Verhältnis von Aufwand zu Schutzwirkung ist kaum zu schlagen.
Supply-Chain-Attacks werden nicht weniger. event-stream (2018), ua-parser-js (2021), colors.js (2022), axios (2026) — der Trend ist klar. Die Frage ist nicht ob, sondern wann die nächste Library betroffen ist. Automatisierte Checks sind kein Nice-to-have mehr.
Häufig gestellte Fragen
Nein. save-exact verhindert, dass npm automatisch auf eine neuere (möglicherweise kompromittierte) Version upgradet. Wenn eine bereits installierte Version nachträglich kompromittiert wird — wie bei axios — schützt euch nur ein aktiver Vulnerability-Check wie der OSV.dev-Hook oder npm audit.
