Axios npm Supply Chain Angriff 2026: Sind Ihre Apps betroffen?
Sicherheitswarnung — Axios npm-Paket kompromittiert
Am 31. März 2026 wurden zwei bösartige Versionen der weit verbreiteten Axios HTTP-Bibliothek auf npm veröffentlicht: 1.14.1 und 0.30.4. Microsoft Threat Intelligence hat den Angriff Sapphire Sleet, einem nordkoreanischen staatlichen Akteur, zugeschrieben. Beide Versionen installieren beim Ausführen von npm install automatisch einen Remote Access Trojan (RAT) für Windows, macOS und Linux.
Quick-Checkliste: Bin ich betroffen?
Arbeiten Sie diese Punkte der Reihe nach ab. Wenn ein Punkt zutrifft, folgen Sie sofort den Maßnahmen weiter unten.
package.json prüfen
Suchen Sie nach Axios in Ihren Abhängigkeiten. Jede Version, die auf 1.14.1 oder 0.30.4 auflöst, ist betroffen.
# Gefährlich — diese Versionsbereiche können auf die Schadversion aufgelöst haben "axios": "^1.14.0" ← löst auf 1.14.1 auf "axios": "^0.30.0" ← löst auf 0.30.4 auf "axios": "1.14.1" ← direkt auf Schadversion gepinnt
Lock-Datei prüfen
Die Lock-Datei (package-lock.json oder yarn.lock) enthält die exakt aufgelöste Version. Suchen Sie nach beiden Paketnamen:
# In package-lock.json oder yarn.lock suchen nach: "axios@1.14.1" "axios@0.30.4" "plain-crypto-js" ← die injizierte Schadabhängigkeit
Das Vorhandensein von plain-crypto-js in einer Lock-Datei ist ein eindeutiges Warnsignal — unabhängig von der Axios-Version.
node_modules prüfen
Falls node_modules lokal oder in einem Container-Image vorhanden ist:
ls node_modules | grep plain-crypto-js cat node_modules/axios/package.json | grep '"version"'
CI/CD-Pipeline-Logs prüfen
Durchsuchen Sie Ihre Build-Logs nach npm install- oder npm ci-Ausführungen zwischen dem 31. März und dem 2. April 2026, bei denen Axios installiert wurde. Wenn Ihre Pipeline auf gemeinsam genutzten Build-Agenten läuft, können diese Maschinen kompromittiert sein — auch wenn Ihr Anwendungscode selbst sauber ist.
Netzwerkverbindungen und Persistenz-Artefakte prüfen
Prüfen Sie auf ausgehenden Traffic zur bekannten C2-Infrastruktur und auf vom RAT hinterlassene Dateien:
| Plattform | Prüfen auf |
|---|---|
| Alle | Ausgehende Verbindungen zu sfrclak.com:8000 oder IP 142.11.206.73 |
| macOS | /Library/Caches/com.apple.act.mond |
| Windows | %PROGRAMDATA%\wt.exe, Registry-Key HKCU\...\Run\MicrosoftUpdate |
| Linux | /tmp/ld.py |
npm audit ausführen
npm audit # oder mit sauberem Install zuerst: npm ci && npm audit
Was ist passiert — der Angriff in Kürze
Die Angreifer veröffentlichten ein gefälschtes Paket, plain-crypto-js@4.2.1, und injizierten es als Abhängigkeit in axios@1.14.1 und axios@0.30.4. Der eigentliche Quellcode von Axios wurde nicht verändert — die Schadsoftware versteckte sich in der Abhängigkeit und wurde automatisch über npm's postinstall-Hook ausgeführt. Es war keine Benutzerinteraktion erforderlich.
Jedes Projekt, das npm install oder npm update mit einem Versionsbereich wie ^1.14.0 ausführte, zog automatisch die Schadversion. Das ist ein klassischer Supply-Chain-Angriff: Die Anwendung selbst sieht sauber aus; der Einbruch passiert auf der Ebene der Abhängigkeitsinstallation.
Nach der Ausführung löschte der Loader seine eigenen Spuren und ersetzte das Paket-Manifest durch eine sauber aussehende Stub-Datei, was die Forensik nach einem Vorfall erheblich erschwert. Der bösartige postinstall-Hook enthielt zudem Logik, um bei späteren Updates erneut eine Infektion zu versuchen.
Warum Sie eine Software Bill of Materials (SBOM) benötigen
Eine Software Bill of Materials (SBOM) — zu Deutsch: Software-Stückliste — ist ein vollständiges, maschinenlesbares Verzeichnis aller Komponenten in Ihrer Software: jede Bibliothek, jedes Paket und jede transitive Abhängigkeit bis zur exakten Version. Denken Sie an die Zutatenliste auf einem Lebensmittelprodukt — nur für Ihre Anwendung.
Fertigungsunternehmen kennen das Konzept seit Jahrzehnten: Eine Stückliste ermöglicht es, bei einem Materialmangel oder einem Qualitätsproblem sofort zu wissen, welche Produkte betroffen sind. Dasselbe Prinzip gilt für Software: Wenn eine Schwachstelle wie dieser Axios-Angriff bekannt wird, kann eine SBOM die Frage „Sind wir betroffen?“ in Minuten statt Stunden oder Tagen beantworten.
Ohne SBOM
- ✗ Manuelle Suche über alle Repositories
- ✗ Stunden, um Betroffenheit zu ermitteln
- ✗ Transitive Abhängigkeiten leicht übersehen
- ✗ Kein Audit-Trail für Compliance (NIS2, ISO 27001)
Mit SBOM
- ✓ Alle Projekte in Minuten abfragbar
- ✓ Transitive Abhängigkeiten automatisch erfasst
- ✓ Maschinenlesbar — in Tooling integrierbar
- ✓ Erfüllt NIS2-, ISO-27001- und Kunden-Auditanforderungen
SBOM für Node.js-Projekte generieren
npm hat eine integrierte SBOM-Unterstützung. Eine SBOM im CycloneDX-Format generieren Sie mit:
# SBOM im CycloneDX-JSON-Format generieren (npm >= 7) npm sbom --sbom-format cyclonedx --sbom-type application > sbom.json # Oder mit einem dedizierten Tool (mehr Funktionen, unterstützt Monorepos) npx @cyclonedx/cyclonedx-npm --output-file sbom.json
Die zwei gängigsten SBOM-Standards sind CycloneDX (OWASP) und SPDX (Linux Foundation). Beide werden von Security-Tooling weitgehend unterstützt. CycloneDX ist für Vulnerability-Management-Anwendungsfälle in der Praxis häufig vorzuziehen.
Maßnahmen — Was tun, wenn Sie betroffen sind?
Sofort (innerhalb der nächsten Stunde)
- Axios in
package.jsonauf eine sichere Version pinnen:"axios": "1.14.0"(exakt, kein Caret) npm cache clean --forceausführen, um gecachte Schadpakete zu entfernennpm ciausführen, um aus der aktualisierten Lock-Datei neu zu installieren- Alle Secrets und Credentials auf betroffenen Systemen rotieren — API-Keys, Tokens, Datenbankpasswörter, SSH-Schlüssel
- Ausgehenden Traffic zu
sfrclak.comund142.11.206.73auf Firewall-Ebene sperren
Kurzfristig (innerhalb des Tages)
- Alle Systeme auditieren, auf denen zwischen dem 31. März und dem 2. April 2026
npm installausgeführt wurde — inklusive CI/CD-Build-Agents und Entwicklermaschinen - Persistenz-Artefakte entfernen (siehe Checkliste oben)
- Windows: Registry-Key
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdateentfernen und%PROGRAMDATA%\wt.exelöschen - Zertifikate und Signing-Keys, die auf betroffenen Build-Systemen zugänglich waren, neu ausstellen
- Einen
overrides-Block inpackage.jsonhinzufügen, um die Axios-Version auch für transitive Abhängigkeiten zu erzwingen
// package.json — sichere Version auch für transitive Abhängigkeiten erzwingen
{
"overrides": {
"axios": "1.14.0"
}
}Strukturelle Verbesserungen (diese Woche)
- Alle Produktionsabhängigkeiten von Versionsbereichen (
^x.y.z) auf exakte Versionen umstellen - In CI-Pipelines
npm cistattnpm installverwenden — respektiert die Lock-Datei exakt und schlägt fehl, wenn sie nicht synchron ist npm audit --audit-level=moderateals fehlschlagenden Schritt in der CI-Pipeline hinzufügennpm ci --ignore-scriptsin CI erwägen, um postinstall-Hooks zu blockieren — das hätte diesen Angriff vollständig verhindert- SBOM als Teil der Build-Artefakte generieren und speichern
Wie DeViLink Supply-Chain-Sicherheit umsetzt
Supply-Chain-Angriffe sind kein neues Phänomen, werden aber zunehmend raffinierter. Hier beschreiben wir unseren Ansatz für Abhängigkeitssicherheit über alle Kundenprojekte — und was wir als Baseline-Praxis für jedes Entwicklungsteam empfehlen.
SBOM als Standard-Build-Artefakt
Jedes Projekt, das wir ausliefern, enthält eine CycloneDX-SBOM, die zur Build-Zeit generiert und zusammen mit dem Release-Artefakt gespeichert wird. Das ist keine einmalige Übung — sie wird bei jedem Build neu generiert und spiegelt immer den tatsächlich installierten Abhängigkeitsbaum wider, einschließlich transitiver Abhängigkeiten. Wenn eine Sicherheitsmeldung veröffentlicht wird, können wir alle aktiven Projekt-SBOMs in Minuten abgleichen und ermitteln, welche Kunden betroffen sind.
Lock-File-Disziplin
Lock-Dateien (package-lock.json oder yarn.lock) werden immer in die Versionskontrolle eingecheckt und wie erstklassige Artefakte behandelt. CI-Pipelines verwenden ausschließlich npm ci — nicht npm install — was sicherstellt, dass der installierte Abhängigkeitsbaum exakt dem entspricht, was geprüft und freigegeben wurde. Ein Pull Request, der die Lock-Datei ändert, erhält dieselbe Prüftiefe wie jede andere Code-Änderung.
Das allein hätte den Axios-Angriff nicht verhindert (die Lock-Datei wäre bei einem lokalen npm install des Entwicklers aktualisiert worden), aber Lock-File-Disziplin bedeutet, dass das Update als Diff in einem Pull Request sichtbar gewesen wäre — ein menschlicher Kontrollpunkt, bevor die Schadversion die Produktion erreicht hätte.
Exaktes Versions-Pinning in Produktion
Wir verwenden kein Caret (^) oder Tilde (~) in Produktionsabhängigkeiten. Jede Produktionsabhängigkeit wird auf eine exakte Version gepinnt. Upgrades sind intentional, durchlaufen einen dedizierten Pull Request und werden vor dem Deployment getestet. Das eliminiert den "Überraschungs-Update"-Vektor, der diesen Axios-Angriff gegenüber Projekten mit ^1.14.0 so effektiv machte.
CI/CD Security Gate
Jede CI-Pipeline enthält ein Security Gate, das vor dem Deployment ausgeführt wird:
# In jeder CI-Pipeline (GitHub Actions, GitLab CI, etc.) - npm ci --ignore-scripts # Blockiert bösartige postinstall-Hooks - npm audit --audit-level=high # Build schlägt bei high/critical CVEs fehl - npm sbom --sbom-format cyclonedx > sbom.json # SBOM-Artefakt generieren
Das --ignore-scripts-Flag ist die wirksamste einzelne Maßnahme gegen den hier verwendeten Angriffsvektor. Der Schadcode in plain-crypto-js@4.2.1 lief ausschließlich über den postinstall-Hook. Das Deaktivieren von Scripts blockiert ihn vollständig.
Advisory-Monitoring und proaktive Kundenkommunikation
Wir abonnieren Sicherheitsmeldungen der GitHub Advisory Database, OSV (Open Source Vulnerabilities) und ökosystem-spezifischer Feeds. Wenn eine Meldung veröffentlicht wird, die häufig verwendete Pakete betrifft, führen wir sofort einen SBOM-Abgleich über alle aktiven Kundenprojekte durch. Betroffene Kunden erhalten eine schriftliche Benachrichtigung mit einer Schweregradbewertung und einem konkreten Maßnahmenplan — bevor sie fragen müssen.
Abhängigkeitsprüfung in Pull Requests
Jeder PR, der package.json oder die Lock-Datei ändert, wird für eine explizite Abhängigkeitsprüfung markiert. Wir nutzen GitHubs Dependency Review Action, um neu eingeführte Pakete, Versionsänderungen und bekannte Schwachstellen im Diff sichtbar zu machen — bevor der Branch gemergt wird. Bei Projekten mit erhöhten Sicherheitsanforderungen führen wir zusätzlich eine manuelle Prüfung neuer transitiver Abhängigkeiten vor der Freigabe durch.
Privates Registry für sicherheitskritische Workloads
Für Kunden in regulierten Branchen oder mit erhöhten Sicherheitsanforderungen empfehlen und konfigurieren wir ein privates npm-Registry (Verdaccio oder GitHub Packages) als Proxy vor dem öffentlichen Registry. Das ermöglicht die Einschränkung erlaubter Pakete, das Caching genehmigter Versionen und das Blockieren von Paketen, die postinstall-Scripts einführen oder eine interne Prüfung nicht bestehen. Es fügt eine zusätzliche Schicht zwischen dem öffentlichen npm-Ökosystem und Ihrer Produktions-Build-Pipeline ein.
Die ehrliche Einschätzung
Keine Sicherheitspraxis eliminiert Supply-Chain-Risiken vollständig. Der Axios-Angriff war ausgefeilt: Das Schadpaket wirkte legitim, hatte eine Veröffentlichungshistorie und hinterließ keine Spuren im Laufzeitcode der Anwendung. Selbst ein Team mit guter Sicherheitshygiene hätte während des 18-stündigen Zeitfensters, bevor die Pakete entfernt wurden, exponiert sein können.
Was gute Praxis leistet, ist die Reduzierung der Angriffsfläche und die Beschleunigung der Reaktionszeit. Eine SBOM wandelt eine tagelange Untersuchung in eine 10-minütige Abfrage um. Exaktes Versions-Pinning bedeutet, dass man nur exponiert war, wenn man das Upgrade bewusst durchgeführt hat. --ignore-scripts in CI hätte die Schadroutine vollständig blockiert. Mehrschichtige Maßnahmen greifen auch dann, wenn einzelne Schichten versagen.
Nicht sicher, ob Ihre Projekte betroffen sind?
Wir können einen schnellen SBOM-basierten Abhängigkeits-Audit über Ihre Codebasis durchführen und Ihnen innerhalb eines Werktages eine klare Antwort geben. Wir prüfen auch Ihre CI/CD-Pipeline auf Supply-Chain-Sicherheitslücken und erstellen einen priorisierten Maßnahmenplan.
