Das nicht ganz so versteckte Muster beim Axios-Angriff
Interlynk
Was ist passiert?
Am 31. März 2026 wurden zwei neue Versionen von axios – der am weitesten verbreiteten HTTP-Client-Bibliothek im JavaScript-Ökosystem – über ein kompromittiertes Maintainer-Konto auf npm veröffentlicht. Die bösartigen 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 stillschweigend einen plattformübergreifenden Remote-Access-Trojaner (RAT) auf jedem Entwicklerrechner, in jeder CI/CD-Pipeline und in jeder Produktionsumgebung bereitstellte, in der ein routinemäßiges npm install ausgeführt wurde.
Sowohl die Threat Intelligence Group von Google als auch Threat Intelligence von Microsoft schrieben den Angriff UNC1069 / Sapphire Sleet zu, einem finanziell motivierten Bedrohungsakteur mit Verbindungen zu Nordkorea, der seit mindestens 2018 aktiv ist. Die bösartigen Versionen waren ungefähr drei Stunden lang verfügbar – gerade lange genug, um eine massive nachgelagerte Gefährdung zu verursachen, bevor npm sie entfernte.
Wenn Ihre Organisation irgendeine Node.js-Software verwendet, ist die Wahrscheinlichkeit hoch, dass axios irgendwo in Ihrem Abhängigkeitsbaum enthalten ist – selbst wenn kein Entwickler es jemals ausdrücklich hinzugefügt hat. Das ist die Natur transitiver Abhängigkeiten. Und genau das macht diesen Angriff so gefährlich.
Der Angriff, Schritt für Schritt
Die Kompromittierung von axios folgte einer präzisen operativen Abfolge, die Sicherheitsforscher nun vollständig dokumentiert haben:
Schritt 1 - Diebstahl von Zugangsdaten. Der Angreifer erlangte ein langlebiges klassisches npm-Access-Token für das Konto von @jasonsaayman, dem primären axios-Maintainer. Obwohl für das Konto MFA konfiguriert war, umging der Angreifer dies, indem er das gestohlene Token direkt verwendete – eine bekannte Lücke, wenn Legacy-Token neben OIDC-basierten Publishing-Workflows koexistieren.
Schritt 2 - Kontoübernahme. Die registrierte E-Mail-Adresse des Maintainer-Kontos wurde unauffällig von der legitimen Gmail-Adresse auf eine Proton-Mail-Adresse (ifstap@proton.me) unter Kontrolle des Angreifers geändert – ein häufiger Pivot, um den echten Eigentümer auszusperren.
Schritt 3 - Vorabbereitstellung des schädlichen Pakets. Bevor er axios selbst anfasste, veröffentlichte der Angreifer plain-crypto-js@4.2.0 als sauberen Köder, um Registry-Historie und Glaubwürdigkeit aufzubauen, gefolgt von plain-crypto-js@4.2.1 – dem Fahrzeug zur Auslieferung der Schadlast.
Schritt 4 - Vergiftung beider Release-Zweige. Innerhalb eines 39-minütigen Zeitfensters veröffentlichte der Angreifer axios@1.14.1 (als latest getaggt) und axios@0.30.4 (als legacy getaggt). In beide Versionen wurde plain-crypto-js@4.2.1 als Abhängigkeit injiziert. Das Taggen beider Kanäle maximierte den Wirkungsradius über Projekte hinweg, die entweder die aktuelle oder die Legacy-axios-API verwenden.
Schritt 5 - Stille Ausführung nach der Installation. Das bösartige plain-crypto-js deklarierte einen Post-Install-Lifecycle-Hook. In dem Moment, in dem eine Umgebung npm install ausführte, wurde setup.js automatisch ausgeführt – keine Benutzerinteraktion erforderlich. Innerhalb von zwei Sekunden nach der Installation rief die Malware bereits den C2-Server des Angreifers unter sfrclak[.]com:8000 bei der IP (142.11.206[.]73) auf.
Schritt 6 - Plattformspezifische RAT-Bereitstellung. Der Dropper erkannte das Betriebssystem des Hosts und stellte eine angepasste Second-Stage-Payload bereit – ein plattformübergreifendes RAT namens WAVESHAPER.V2 – für macOS, Windows und Linux. Das RAT begann sofort mit der Systemaufklärung, enumerierte Verzeichnisse und laufende Prozesse und exfiltrierte Zugangsdaten, SSH-Schlüssel, Cloud-Token und API-Geheimnisse.
Schritt 7 - Provenance-Lücke als Tarnung. Legitime axios-Releases enthalten immer OIDC-Provenance-Metadaten und SLSA-Build-Attestierungen, die das npm-Paket auf einen bestimmten GitHub-Actions-Run zurückführen. Die bösartigen Versionen hatten nichts davon. Verteidiger, die Provenance-Prüfungen eingerichtet hatten, bemerkten dies sofort; diejenigen, die sich auf traditionelle Vulnerability-Scanner verließen, sahen nichts – denn plain-crypto-js hatte keine CVE.
Aufkommendes Angriffsmuster
Der Axios-Angriff ist der jüngste Datenpunkt in einem lang andauernden und sich beschleunigenden Trend.
Jeder Schritt dieses Playbooks wurde schon zuvor ausgeführt – oft von derselben Klasse 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 unentdeckt.
SolarWinds Orion (2020): Akteure eines Nationalstaats (Nobelium/APT29) kompromittierten die SolarWinds-Build-Pipeline und fügten die SUNBURST-Backdoor in signierte Software-Updates ein, die an 18.000 Organisationen verteilt wurden, darunter US-Bundesbehörden. Der Angriff blieb 14 Monate lang unentdeckt.
ua-parser-js (2021): Ein gekapertes npm-Konto wurde genutzt, um bösartige Versionen einer Bibliothek mit 8 Millionen wöchentlichen Downloads zu veröffentlichen; dabei wurden Krypto-Miner und Zugangsdaten-Diebe eingesetzt – derselbe Account-Übernahme-Vektor, der fünf Jahre später 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 einfügte, die auf die OpenSSH-Authentifizierung unter Fedora, Ubuntu und Debian abzielte. Fast zufällig entdeckt, als ein Microsoft-Ingenieur Anomalien bei der SSH-Latenz bemerkte.
tj-actions/changed-files (2025): Eine GitHub Action, die in Tausenden von CI/CD-Workflows verwendet wird, wurde durch Tag Poisoning kompromittiert, wodurch in großem Maßstab Geheimnisse aus Runner-Umgebungen exfiltriert wurden.
Trivy / TeamPCP (2026): Tage vor dem Axios-Angriff stahl der Bedrohungsakteur TeamPCP ein Zugriffstoken aus dem GitHub-Actions-Workflow des Trivy-Sicherheitsscanners, vergiftete über Nacht 76 Versions-Tags, sammelte Zugangsdaten aus CI/CD-Umgebungen und nutzte gestohlene npm-Tokens, um einen Wurm (CanisterWorm) über 66+ npm-Pakete hinweg selbst zu verbreiten – alles innerhalb weniger Tage rund um den Axios-Angriff.
Der gemeinsame Nenner all dieser Angriffe: eine vertrauenswürdige Komponente kompromittieren, das implizite Vertrauen des Ökosystems ausnutzen und jeden nachgelagerten Nutzer automatisch erreichen. Der Axios-Angriff hat das nicht erfunden – er hat es in großem Maßstab perfektioniert.
Die Beschleunigung ist real
Lieferkettenangriffe waren früher chirurgische, geduldige Operationen, die über Monate oder Jahre hinweg abliefen. Die XZ-Utils-Hintertür benötigte zwei Jahre Social Engineering. SolarWinds blieb 14 Monate lang unentdeckt. Heute wurde der Axios-Angriff innerhalb von 6 Minuten nach der Veröffentlichung von verhaltensanalytischen Tools erkannt – und traf dennoch über 135 Endpunkte, bevor er eingedämmt wurde. Der Zeitrahmen hat sich von Jahren auf Stunden verkürzt. KI wird inzwischen von Angreifern eingesetzt, um bösartige Pakete zu erzeugen, die Verbreitung zu automatisieren und Schwachstellen mit Maschinengeschwindigkeit zu finden, während KI-Coding-Agenten auf Entwicklerseite bekannte anfällige Abhängigkeitsversionen mit einer um 50 % höheren Rate als Menschen auswählen. Die Angriffsfläche wächst schneller als die Verteidigung.
Bewährte Verfahren zur Schadensbegrenzung
Kein einzelnes Kontrollmittel stoppt jeden Supply-Chain-Angriff. Eine wirksame Verteidigung erfordert mehrere unabhängige Schichten, die über den gesamten SDLC hinweg wirken:
Wissen, was Sie ausführen – jederzeit
Sie können einen Supply-Chain-Angriff auf eine Komponente, von der Sie nicht wussten, dass Sie sie verwenden, weder erkennen noch darauf reagieren. Die automatisierte SBOM-Erstellung, die im gesamten SDLC eingebettet ist – nicht als einmaliges Audit-Ergebnis, sondern als kontinuierliche Aufzeichnung dessen, was genau in jedem Build enthalten ist – ist das grundlegende Kontrollmittel. Eine zur Build-Zeit erstellte SBOM erfasst transitive Abhängigkeiten wie plain-crypto-js, bevor sie überhaupt die Produktion erreichen.
Abhängigkeiten festschreiben. Lockfiles einchecken.
Gleitende Versionsbereiche (^1.14.0, ~1.14.0) sind eine offene Einladung für Supply-Chain-Angriffe. Jedes Update, das in den Bereich fällt, wird automatisch installiert. Auf exakte Versionen festschreiben. Ihre package-lock.json einchecken. In allen CI/CD-Pipelines npm ci verwenden (nicht npm install) – es beachtet das Lockfile exakt und führt nicht stillschweigend ein Upgrade auf ein bösartiges Patch-Release durch.Provenienz und Build-Attestierung durchsetzen
OIDC-Provenienzmetadaten und SLSA Level 2+ für alle kritischen Drittanbieterpakete verlangen. Das deutlichste frühe Signal beim axios-Angriff war das Fehlen von Provenienz bei neuen Versionen eines Pakets, das diese immer enthalten hatte. Das Fehlen von Provenienz bei einer neuen Version eines bedeutenden Pakets sollte einen automatischen Alarm auslösen – nicht erst im Nachhinein eine manuelle Untersuchung.Eine Veröffentlichungs-Cooldown-Richtlinie anwenden
Eine Mindestalter-Richtlinie für Releases implementieren – die Installation von Paketen blockieren, die innerhalb der letzten 72 Stunden veröffentlicht wurden. Das gibt der Sicherheits-Community Zeit, neue Releases zu analysieren, bevor sie in Ihre Supply Chain gelangen. Die bösartigen axios-Versionen waren nur drei Stunden online; eine 72-Stunden-Cooldown hätte sie für die große Mehrheit der Organisationen vollständig blockiert.Postinstall-Skripte deaktivieren oder prüfen
Die gesamte axios-Angriffskette hing am npm-Lifecycle-Hook postinstall. Die meisten Produktions-Builds benötigen keine Lifecycle-Skripte von Drittanbieterpaketen. In CI/CD-Pipelines npm install --ignore-scripts verwenden, wo Skripte nicht erforderlich sind. Wenn Skripte notwendig sind, diese prüfen und explizit auf eine Allowlist setzen.Zur Laufzeit auf anomales Verhalten überwachen
Traditionelle Vulnerability-Scanner suchen nach bekannten CVEs. Supply-Chain-Angriffe wie axios führen völlig neue Pakete ohne CVE-Historie ein. Verhaltensbasiertes Monitoring – das Beobachten unerwarteter ausgehender Netzwerkverbindungen aus Build-Umgebungen, neuer durch npm install gestarteter Prozesse oder anomaler Zugriffsmuster auf Anmeldedaten – erfasst, was signaturbasierte Tools übersehen. Innerhalb von zwei Sekunden nach der Installation meldete sich der axios-RAT bereits bei seinem Command-and-Control-Server. Die Überwachung ausgehender Netzwerkverbindungen von CI-Runnern hätte ihn sofort erkannt.Anmeldedaten konsequent rotieren und langlebige Tokens widerrufen
Der axios-Angriff war möglich, weil ein langlebiges npm-Access-Token direkten Veröffentlichungszugriff bot – und damit alle OIDC-basierten Veröffentlichungskontrollen umging, die eingerichtet worden waren. Langlebige Tokens nach Möglichkeit eliminieren. Trusted Publishing mit OIDC einführen. Alle CI/CD-Geheimnisse regelmäßig rotieren und unmittelbar nach jedem Supply-Chain-Vorfall jede Anmeldeinformation, die eine betroffene Umgebung berührt hat, als kompromittiert behandeln.
Interlynk-Kundenerfahrung mit Axios
Als der Axios-Angriff öffentlich wurde, wechselten Sicherheitsteams weltweit in den Notfallreaktionsmodus: Abhängigkeitsbäume prüfen, CI/CD-Logs durchsuchen, Anmeldedaten rotieren, versuchen, die grundlegendste Frage zu beantworten – sind wir betroffen?
Für 77 % der Interlynk-Kunden gab es auf diese Frage sofort eine Antwort. Die oben beschriebenen Best Practices sind keine aspirativen Empfehlungen auf einer Interlynk-Checkliste – sie sind in der Plattform operationalisierte Kontrollen:
Die kontinuierliche SBOM-Generierung, eingebettet über den gesamten SDLC, bedeutete, dass Kunden bereits über einen aktuellen, präzisen Nachweis jeder Abhängigkeit in jedem Build verfügten – einschließlich transitiver Abhängigkeiten wie plain-crypto-js.
Die Überwachung von Open-Source-Risiken kennzeichnete Änderungen der Axios-Version und die Einführung neuer Abhängigkeiten in Echtzeit, anhand kontinuierlich aktualisierter Threat Intelligence.
Die Richtliniendurchsetzung über den gesamten SDLC hinweg – einschließlich Anforderungen zur Dependency-Pinning und Komponenten-Allowlisting – verhinderte für die Mehrheit der Kunden von vornherein, dass die bösartigen Versionen in die Build-Pipelines gelangten.
Die Lieferantenüberwachung verschaffte sofortige Transparenz darüber, welche Pakete in der Stückliste aktive Sicherheitsereignisse aufwiesen, ohne dass eine manuelle Log-Analyse erforderlich war.
Die 23 %, die die Exponierung noch bewerteten, hatten eines gemeinsam: Lücken in der SBOM-Abdeckung für Legacy-Pipelines oder übernommene Codebasen, die noch nicht in die Plattform aufgenommen worden waren. Axios fand die Lücke. Das tut es immer.
Echte Sicherheit: SBOM-Automatisierung über den gesamten SDLC hinweg
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 erfasst hat. Die manuelle SBOM-Erstellung – ein einmaliges Audit-Dokument, das für einen Compliance-Nachweis erstellt wird – bietet keinen Schutz vor einem Supply-Chain-Angriff, der sich in drei Stunden entfaltet und auf Entwicklungsmaschinen beginnt.
Die einzige belastbare Antwort ist die Automatisierung der SBOM-Erstellung und der Richtliniendurchsetzung über den gesamten Software Development Lifecycle hinweg. Nicht als punktueller Export, sondern als kontinuierlicher, lebender Nachweis jeder Komponente in jedem Build, bewertet anhand aktueller Bedrohungsinformationen und organisatorischer Richtlinien – in jeder Phase von der Entwicklung bis zur Produktion.
Das ist besonders wichtig für komplexe Organisationen – solche mit Dutzenden Teams, Hunderten Repositories und einer Mischung aus modernen und Legacy-Codebasen. Die Richtlinienfrage bei einem Supply-Chain-Angriff lautet nie „Befolgen wir in der Theorie Best Practices?“ – sondern „Hat tatsächlich jedes Team, jede Pipeline, jede Entwickler-Workstation die Richtlinie durchgesetzt, als es darauf ankam?“ Manuelle Prozesse und heldenhafte Einzelleistungen auf Teamebene können diese Frage im großen Maßstab nicht konsistent beantworten.
Die Einbettung der SBOM-Erstellung in den SDLC – mit automatisierten Policy-Gates, die nicht konforme Komponenten daran hindern, in der Build-Pipeline weiterzukommen, kontinuierlicher Überwachung von Komponentenänderungen anhand aktueller Bedrohungsinformationen und der Nachverfolgung von Lieferantenrisiken, die Ereignisse wie die Axios-Kompromittierung in Echtzeit sichtbar macht – verwandelt Supply-Chain-Sicherheit von einem reaktiven Incident-Response-Problem in eine proaktive Engineering-Disziplin.
Supply-Chain-Angriffe nehmen zu. Das Zeitfenster zwischen der Veröffentlichung eines bösartigen Pakets und dem ersten Opfer wird heute in Sekunden statt in Tagen gemessen. Die einzigen Organisationen, die nicht hektisch die Frage „Sind wir betroffen?“ beantworten müssen, sind diejenigen, die bereits genau wissen, was in ihrer Software steckt – weil sie die Antwort automatisiert haben.
Sehen Sie, wie Interlynk SBOM über Ihren gesamten SDLC hinweg automatisiert und Supply-Chain-Richtlinien im großen Maßstab durchsetzt. Demo buchen →