Das nicht so gut versteckte Muster im Axios-Angriff
Ingenieurwesen
Was ist passiert?
Am 31. März 2026 wurden zwei neue Versionen von axios – der am weitesten verbreiteten HTTP-Client-Bibliothek im JavaScript-Ökosystem – von einem kompromittierten Maintainer-Konto auf npm veröffentlicht. Die schädlichen Versionen (1.14.1 und 0.30.4) erreichten zusammen über 100 Millionen wöchentliche Downloads. Sie führten eine versteckte Abhängigkeit namens plain-crypto-js ein, die still und leise einen plattformübergreifenden Remote-Access-Trojaner (RAT) auf jedem Entwicklerrechner, jeder CI/CD-Pipeline und jeder Produktionsumgebung installierte, die ein routinemäßiges npm install ausführten.
Sowohl die Google Threat Intelligence Group als auch Microsoft Threat Intelligence ordneten den Angriff UNC1069 / Sapphire Sleet zu, einem finanziell motivierten Bedrohungsakteur mit Verbindungen zu Nordkorea, der seit mindestens 2018 aktiv ist. Die schädlichen Versionen waren etwa drei Stunden lang online – gerade lange genug, um massive nachgelagerte Auswirkungen zu verursachen, bevor npm sie entfernte.
Wenn Ihr Unternehmen Node.js-Software verwendet, besteht eine hohe Wahrscheinlichkeit, dass axios irgendwo in Ihrem Abhängigkeitsbaum vorhanden ist – selbst wenn kein Entwickler es jemals explizit hinzugefügt hat. Das ist das Wesen transitiver Abhängigkeiten. Und genau das macht diesen Angriff so gefährlich.
Der Angriff, Schritt für Schritt
Die Axios-Kompromittierung folgte einem präzisen Betriebsablauf, den Sicherheitsforscher nun im Detail dokumentiert haben:
Schritt 1 – Diebstahl von Zugangsdaten. Der Angreifer erlangte ein langlebiges klassisches npm-Zugriffstoken für das Konto von @jasonsaayman, dem Haupt-Maintainer von axios. Obwohl für das Konto MFA konfiguriert war, umging der Angreifer dies, indem er das gestohlene Token direkt verwendete – eine bekannte Schwachstelle, wenn Legacy-Token parallel zu OIDC-basierten Veröffentlichungs-Workflows existieren.
Schritt 2 – Kontoübernahme. Die registrierte E-Mail-Adresse des Maintainer-Kontos wurde heimlich von der legitimen Gmail-Adresse in eine Proton Mail-Adresse (ifstap@proton.me) unter der Kontrolle des Angreifers geändert – ein üblicher Schritt, um den echten Eigentümer auszusperren.
Schritt 3 – Vorbereitung des bösartigen Pakets. Bevor axios selbst manipuliert wurde, veröffentlichte der Angreifer plain-crypto-js@4.2.0 als sauberes Ablenkungsmanöver, um eine Registry-Historie und Glaubwürdigkeit aufzubauen, gefolgt von plain-crypto-js@4.2.1 – dem Träger für die Schadsoftware.
Schritt 4 – Kompromittierung beider Release-Zweige. Innerhalb eines Zeitfensters von 39 Minuten veröffentlichte der Angreifer axios@1.14.1 (als „latest“ getaggt) und axios@0.30.4 (als „legacy“ getaggt). In beiden Versionen wurde plain-crypto-js@4.2.1 als Abhängigkeit injiziert. Die Kennzeichnung beider Kanäle maximierte die Reichweite über alle Projekte hinweg, die entweder die aktuelle oder die alte axios-API verwendeten.
Schritt 5 – Stille Ausführung nach der Installation. Das bösartige plain-crypto-js deklarierte einen Post-Install-Lifecycle-Hook. Sobald eine Umgebung „npm install“ ausführte, wurde setup.js automatisch gestartet – ganz ohne Benutzerinteraktion. Innerhalb von zwei Sekunden nach der Installation kontaktierte die Schadsoftware bereits den C2-Server des Angreifers unter sfrclak[.]com:8000 bei der IP-Adresse (142.11.206[.]73).
Schritt 6 – Plattformspezifische RAT-Bereitstellung. Der Dropper erkannte das Host-Betriebssystem und installierte eine maßgeschneiderte Payload der zweiten Stufe – einen plattformübergreifenden RAT namens WAVESHAPER.V2 – für macOS, Windows und Linux. Der RAT begann sofort mit der Systemanalyse, erfasste Verzeichnisse, laufende Prozesse und leitete Zugangsdaten, SSH-Schlüssel, Cloud-Token sowie API-Geheimnisse ab.
Schritt 7 – Herkunftslücke als Tarnung. Legitime Axios-Releases enthalten immer OIDC-Herkunfts-Metadaten und SLSA-Build-Attestierungen, die das npm-Paket mit einem bestimmten GitHub Actions-Lauf verknüpfen. Die schädlichen Versionen wiesen diese nicht auf. Abwehrkräfte, die eine Herkunftsprüfung eingerichtet hatten, bemerkten dies sofort; diejenigen, die sich auf traditionelle Schwachstellen-Scanner verließen, sahen nichts – da plain-crypto-js keine CVE hatte.
Aufkommendes Angriffsmuster
Der axios-Angriff ist der jüngste Datenpunkt in einem lang anhaltenden und sich beschleunigenden Trend.
Jeder Schritt dieses Handbuchs wurde schon einmal ausgeführt – oft von derselben Kategorie von Bedrohungsakteuren und gegen ähnlich kritische Open-Source-Pakete:
event-stream (2018): Ein böswilliger Mitwirkender erlangte Veröffentlichungsrechte für ein inaktives npm-Paket mit 2 Millionen wöchentlichen Downloads und schleuste eine Backdoor ein, die auf eine bestimmte Bitcoin-Wallet abzielte. Der Angriff blieb wochenlang unbemerkt.
SolarWinds Orion (2020): Staatliche Akteure (Nobelium/APT29) kompromittierten die Build-Pipeline von SolarWinds und bauten die SUNBURST-Backdoor in signierte Software-Updates ein, die an 18.000 Organisationen, darunter US-Bundesbehörden, verteilt wurden. Der Angriff blieb 14 Monate lang unbemerkt.
ua-parser-js (2021): Ein gekapertes npm-Konto wurde verwendet, um bösartige Versionen einer Bibliothek mit 8 Millionen wöchentlichen Downloads zu veröffentlichen. Dabei wurden Cryptominer und Credential Stealer eingesetzt – derselbe Vektor zur Kontoübernahme, der fünf Jahre später auch gegen axios verwendet wurde.
XZ Utils (2022–2024): Ein hochentwickelter Bedrohungsakteur verbrachte fast zwei Jahre damit, das Vertrauen der Maintainer einer zentralen Linux-Komprimierungsbibliothek zu gewinnen, bevor er eine Backdoor einschleuste, die auf die OpenSSH-Authentifizierung unter Fedora, Ubuntu und Debian abzielte. Entdeckt wurde dies fast durch Zufall von einem Microsoft-Ingenieur, dem Latenzanomalien bei SSH auffielen.
tj-actions/changed-files (2025): Eine GitHub-Action, die in Tausenden von CI/CD-Workflows verwendet wird, wurde durch Tag-Poisoning kompromittiert, wodurch Geheimnisse in großem Stil aus Runner-Umgebungen abgezogen wurden.
Trivy / TeamPCP (2026): Nur wenige Tage vor dem axios-Angriff stahl der Bedrohungsakteur TeamPCP ein Zugriffstoken aus dem GitHub Actions-Workflow des Trivy-Sicherheitsscanners, manipulierte über Nacht 76 Versions-Tags, erbeutete Zugangsdaten aus CI/CD-Umgebungen und nutzte gestohlene npm-Token, um einen Wurm (CanisterWorm) selbstständig auf über 66 npm-Pakete zu verbreiten – und das alles innerhalb weniger Tage vor dem axios-Angriff.
Der rote Faden bei all diesen Angriffen: Eine vertrauenswürdige Komponente kompromittieren, das implizite Vertrauen des Ökosystems ausnutzen und so automatisch jeden nachgelagerten Nutzer erreichen. Der axios-Angriff hat dies nicht neu erfunden – er hat es im großen Maßstab perfektioniert.
Die Beschleunigung ist real
Lieferkettenangriffe waren früher chirurgische, geduldige Operationen, die in Monaten oder Jahren gemessen wurden. Die XZ Utils-Backdoor dauerte zwei Jahre Social Engineering. SolarWinds blieb 14 Monate lang unentdeckt. Heute wurde der Axios-Angriff innerhalb von 6 Minuten nach der Veröffentlichung durch Verhaltensanalysetools identifiziert – und traf dennoch über 135 Endpunkte vor der Eindämmung. Der Zeitrahmen hat sich von Jahren auf Stunden verkürzt. KI wird heute von Angreifern genutzt, um bösartige Pakete zu generieren, die Verbreitung zu automatisieren und Schwachstellen in Maschinengeschwindigkeit zu finden, während KI-Codierungsagenten auf der Entwicklerseite bekannte, anfällige Abhängigkeitsversionen mit Raten auswählen, die um 50 % höher sind als beim Menschen. Die Angriffsfläche wächst schneller als die Verteidigung.
Best Practices zur Schadensminderung
Keine einzelne Sicherheitsmaßnahme hält jeden Supply-Chain-Angriff auf. Eine effektive Verteidigung erfordert mehrere unabhängige Schichten, die über den gesamten SDLC hinweg wirken:
Wissen, was läuft – und zwar immer
Sie können einen Supply-Chain-Angriff auf eine Komponente nicht erkennen oder darauf reagieren, von deren Verwendung Sie nichts wussten. Die automatisierte SBOM-Erstellung, die im gesamten SDLC verankert ist – nicht als einmaliges Audit-Ergebnis, sondern als kontinuierliche Aufzeichnung dessen, was exakt in jedem Build enthalten ist –, stellt die grundlegende Sicherheitsmaßnahme dar. Eine zum Build-Zeitpunkt erstellte SBOM erfasst transitive Abhängigkeiten wie plain-crypto-js, noch bevor diese jemals die Produktion erreichen.
Abhängigkeiten fixieren. Lockfiles committen.
Variable Versionsbereiche (^1.14.0, ~1.14.0) sind eine offene Einladung für Supply-Chain-Angriffe. Jedes Update, das in diesen Bereich fällt, wird automatisch installiert. Fixieren Sie Versionen auf exakte Werte. Committen Sie Ihre package-lock.json. Verwenden Sie npm ci (nicht npm install) in allen CI/CD-Pipelines – dies respektiert das Lockfile exakt und führt keine stillschweigenden Upgrades auf einen bösartigen Patch-Release durch.Provenienz und Build-Attestierung erzwingen
Fordern Sie OIDC-Provenienzmetadaten und SLSA-Level 2+ für alle kritischen Pakete von Drittanbietern. Das deutlichste frühe Signal des axios-Angriffs war das Fehlen einer Provenienz bei neuen Versionen eines Pakets, das diese zuvor immer enthalten hatte. Das Fehlen einer Provenienz bei einer neuen Version eines wichtigen Pakets sollte einen automatischen Alarm auslösen – und nicht erst im Nachhinein eine manuelle Untersuchung.Eine Veröffentlichungs-Cooldown-Richtlinie anwenden
Implementieren Sie eine Richtlinie für ein Mindestalter von Veröffentlichungen – und blockieren Sie die Installation von Paketen, die innerhalb der letzten 72 Stunden veröffentlicht wurden. Dies gibt der Security-Community Zeit, neue Releases zu analysieren, bevor sie in Ihre Lieferkette gelangen. Die bösartigen Versionen von axios waren nur drei Stunden lang online; eine 72-stündige Abkühlungsphase hätte sie für die überwiegende Mehrheit der Organisationen vollständig blockiert.Postinstall-Skripte deaktivieren oder prüfen
Die gesamte axios-Angriffskette basierte auf dem postinstall-Lifecycle-Hook von npm. Die meisten Produktions-Builds benötigen keine Lifecycle-Skripte von Drittanbieter-Paketen. Verwenden Sie npm install --ignore-scripts in CI/CD-Pipelines, in denen keine Skripte erforderlich sind. Wenn Skripte notwendig sind, prüfen Sie diese und setzen Sie sie explizit auf eine Allowlist.Anomales Verhalten zur Laufzeit überwachen
Herkömmliche Schwachstellenscanner suchen nach bekannten CVEs. Supply-Chain-Angriffe wie bei axios führen völlig neue Pakete ohne CVE-Historie ein. Verhaltensüberwachung – wie das Achten auf unerwartete ausgehende Netzwerkverbindungen aus Build-Umgebungen, neue durch npm install gestartete Prozesse oder anomale Zugriffsmuster auf Anmeldedaten – erkennt das, was signaturbasierte Tools übersehen. Innerhalb von zwei Sekunden nach der Installation nahm der axios-RAT bereits Verbindung nach Hause auf. Eine Überwachung des ausgehenden Netzwerkverkehrs von CI-Runnern hätte dies sofort erkannt.Anmeldedaten aggressiv rotieren und langlebige Token widerrufen
Der axios-Angriff war möglich, weil ein langlebiger npm-Zugriffstoken direkten Veröffentlichungszugriff ermöglichte – und damit alle eingerichteten OIDC-basierten Veröffentlichungskontrollen umging. Eliminieren Sie langlebige Token, wo immer dies möglich ist. Setzen Sie auf Trusted Publishing mit OIDC. Rotieren Sie alle CI/CD-Geheimnisse in regelmäßigen Abständen, und behandeln Sie nach jedem Supply-Chain-Vorfall unverzüglich alle Anmeldedaten, die mit einer betroffenen Umgebung in Berührung gekommen sind, als kompromittiert.
Interlynk Kundenerfahrung mit Axios
Als der Axios-Angriff öffentlich wurde, gingen Sicherheitsteams weltweit in den Notfallmodus über: Überprüfung von Abhängigkeitsbäumen, Durchsuchen von CI/CD-Protokollen, Rotation von Zugangsdaten und der Versuch, die brennendste Frage zu beantworten: Sind wir betroffen?
Für 77 % der Interlynk-Kunden gab es auf diese Frage eine sofortige Antwort. Die oben beschriebenen Best Practices sind keine rein theoretischen Empfehlungen auf einer Interlynk-Checkliste – es sind operationalisierte Kontrollen, die direkt in die Plattform integriert sind:
Die kontinuierliche Erstellung von SBOMs, die in den gesamten SDLC eingebettet ist, bedeutet, dass Kunden bereits über eine aktuelle und präzise Erfassung jeder Abhängigkeit in jedem Build verfügten – einschließlich transitiver Abhängigkeiten wie plain-crypto-js.
Die Risikoüberwachung für Open-Source-Software markierte Versionsänderungen von Axios und die Einführung neuer Abhängigkeiten in Echtzeit auf Basis kontinuierlich aktualisierter Bedrohungsdaten.
Die Durchsetzung von Richtlinien im gesamten SDLC – einschließlich Anforderungen zur Fixierung von Abhängigkeiten und Whitelisting von Komponenten – verhinderte bei der Mehrheit der Kunden von vornherein, dass die schädlichen Versionen in die Build-Pipelines gelangten.
Die Lieferantenüberwachung bot sofortige Transparenz darüber, welche Pakete in der Stückliste aktive Sicherheitsereignisse aufwiesen, ohne dass eine manuelle Protokollanalyse erforderlich war.
Die restlichen 23 %, die ihre Gefährdung noch analysierten, hatten eines gemeinsam: Lücken in der SBOM-Abdeckung bei Legacy-Pipelines oder übernommenen Codebasen, die noch nicht in die Plattform integriert worden waren. Axios hat diese Lücke gefunden. Das tut es immer.
Echte Verteidigung: SBOM-Automatisierung über den gesamten SDLC
Organisationen, die auf den Axios-Angriff reagierten, standen vor einer vertrauten Herausforderung: Man kann nicht durchsetzen, was man nicht sehen kann, und man kann nicht sehen, was man nie nachverfolgt hat. Die manuelle Erstellung von SBOMs – ein einmaliges Audit-Dokument, das für ein Compliance-Ergebnis erstellt wird – bietet keinen Schutz gegen einen Angriff auf die Lieferkette, der sich innerhalb von drei Stunden entfaltet und auf Entwicklungsrechnern beginnt.
Die einzig dauerhafte Antwort ist die Automatisierung der SBOM-Erstellung und der Richtliniendurchsetzung über den gesamten Software-Entwicklungslebenszyklus (SDLC) hinweg. Nicht als einmaliger Export zu einem bestimmten Zeitpunkt, sondern als kontinuierliche, lebendige Dokumentation jeder Komponente in jedem Build, die in jeder Phase von der Entwicklung bis zur Produktion mit aktuellen Bedrohungsdaten und Organisationsrichtlinien abgeglichen wird.
Dies ist besonders für komplexe Organisationen von Bedeutung – solche mit Dutzenden von Teams, Hunderten von Repositories und einer Mischung aus modernen und veralteten Codebasen. Die Frage nach den Richtlinien bei einem Angriff auf die Lieferkette lautet nie: „Befolgen wir theoretisch Best Practices?“ – sondern: „Hat jedes Team, jede Pipeline und jede Entwickler-Workstation die Richtlinie tatsächlich durchgesetzt, als es darauf ankam?“ Manuelle Prozesse und Heldentaten auf Team-Ebene können diese Frage im großen Maßstab nicht konsistent beantworten.
Die Einbettung der SBOM-Erstellung in den SDLC – mit automatisierten Richtlinienschranken, die verhindern, dass nicht konforme Komponenten die Build-Pipeline durchlaufen, kontinuierlicher Überwachung auf Komponentenänderungen im Vergleich zu Live-Bedrohungsdaten und der Verfolgung von Lieferantenrisiken, die Ereignisse wie die Axios-Kompromittierung in Echtzeit aufdecken – verwandelt die Sicherheit der Lieferkette von einem reaktiven Problem der Vorfallreaktion in eine proaktive Entwicklungsdisziplin.
Angriffe auf die Lieferkette nehmen an Fahrt auf. Das Zeitfenster zwischen der Veröffentlichung eines schädlichen Pakets und dem ersten Opfer wird mittlerweile in Sekunden gemessen, nicht in Tagen. Die einzigen Organisationen, die nicht hektisch nach der Antwort auf die Frage „Sind wir betroffen?“ suchen müssen, sind diejenigen, die bereits genau wissen, was in ihrer Software steckt – weil sie die Antwort automatisiert haben.
Erfahren Sie, wie Interlynk SBOMs in Ihrem gesamten SDLC automatisiert und Richtlinien für die Lieferkette im großen Maßstab durchsetzt. Demo buchen →