Axios npm-Angriff: Wie ein gekapertes Maintainer-Konto Millionen Entwickler bedrohte

8 Min. Lesezeit

Am 31. März 2026 entdeckte das Sicherheitsunternehmen StepSecurity einen Remote-Access-Trojaner in zwei manipulierten Versionen des npm-Pakets Axios – einer der meistgenutzten JavaScript-Bibliotheken weltweit mit über 100 Millionen Downloads pro Woche. Der Angriff nutzte eine gefälschte Abhängigkeit, ein gekapertes Maintainer-Konto und einen C2-Server, um plattformübergreifend Backdoors auf Entwicklermaschinen zu installieren. Er gilt als einer der raffiniertesten Supply-Chain-Angriffe in der Geschichte des npm-Ökosystems.

Das Wichtigste in Kürze

• Zwei manipulierte Axios-Versionen (1.14.1 und 0.30.4) enthielten einen plattformübergreifenden Remote-Access-Trojaner, der über die Fake-Abhängigkeit plain-crypto-js eingeschleust wurde.
• Der Angriff nutzte ein gekapertes npm-Maintainer-Konto und umging die reguläre GitHub-Actions-Veröffentlichungspipeline.
• Der RAT exfiltriert Credentials wie AWS-Zugangsdaten und API-Keys und löscht nach der Installation seine eigenen Spuren.
• Microsoft Threat Intelligence und Google Threat Intelligence Group ordnen den Angriff nordkoreanischen Akteuren zu (Sapphire Sleet / UNC1069).
• Betroffene Systeme sollten als vollständig kompromittiert behandelt werden – ein einfaches Löschen des RAT reicht nicht aus.

Was passiert ist

Axios ist seit über zehn Jahren eine der beliebtesten JavaScript-Bibliotheken für HTTP-Requests. Obwohl moderne Laufzeitumgebungen wie Node.js und Deno mittlerweile die native Fetch-API unterstützen, bevorzugen Millionen von Entwicklern weiterhin Axios wegen seiner komfortableren API, automatischer JSON-Transformation und eingebauter Interceptors. Diese Verbreitung machte das Paket zu einem idealen Ziel.

Am 30. März 2026 um 23:59 UTC veröffentlichte ein Angreifer die Version 4.2.1 des npm-Pakets plain-crypto-js – ein Paket, das dem legitimen und weit verbreiteten crypto-js zum Verwechseln ähnlich sieht. 22 Minuten später folgte die manipulierte Version 1.14.1 von Axios, getaggt als „latest“. Um 01:00 UTC erschien zusätzlich Version 0.30.4, getaggt als „legacy“. Beide Axios-Versionen enthielten plain-crypto-js als neue Runtime-Abhängigkeit.

Der Angriff war sorgfältig inszeniert. Bereits 18 Stunden zuvor hatte der Angreifer eine harmlose Version 4.2.0 von plain-crypto-js publiziert – eine Decoy-Version, die bei automatisierten Scans keinen Alarm auslöste. Erst die Version 4.2.1 enthielt den eigentlichen Schadcode.

Normalerweise werden Axios-Releases über GitHub Actions veröffentlicht. Die manipulierten Versionen wurden stattdessen direkt über ein kompromittiertes npm-Konto publiziert. Der Angreifer hatte das Konto des Haupt-Maintainers jasonsaayman übernommen und die registrierte E-Mail-Adresse gegen eine Proton-Mail-Adresse ausgetauscht. Wie genau die Kontoübernahme gelang, ist Stand April 2026 nicht öffentlich bestätigt.

npm entfernte beide Versionen innerhalb von etwa zwei bis drei Stunden. Bei einem Paket mit über 100 Millionen wöchentlichen Downloads sind selbst wenige Stunden ein kritisches Zeitfenster.

Anatomie des Angriffs: Vom postinstall-Skript zum C2-Server

Der Quellcode von Axios selbst enthielt keinen Schadcode. Die Manipulation beschränkte sich auf das Hinzufügen von plain-crypto-js als Abhängigkeit in der package.json. Wer nur den Axios-Code auditiert hätte, hätte nichts gefunden. Die eigentliche Waffe steckte in der neuen Dependency.

Das Paket plain-crypto-js enthielt ein postinstall-Skript namens setup.js. Sobald ein Entwickler npm install ausführte, lief im Hintergrund ein zweistufig XOR-verschleiertes JavaScript ab – der sogenannte RAT-Dropper. Dieser arbeitete in vier Phasen:

Phase 1 – Systemerkennung: Das Skript identifiziert das Betriebssystem des Zielsystems. Unterstützt werden macOS, Windows und Linux.

Phase 2 – Payload-Download: Der Dropper baut eine Verbindung zum Command-and-Control-Server auf (Domain: sfrclak.com, IP: 142.11.206.73, Port 8000). Von dort wird ein plattformspezifisches Binary heruntergeladen.

Phase 3 – Ausführung: Der RAT wird auf die Festplatte geschrieben und gestartet. Unter macOS landet er als com.apple.act.mond im Library-Cache und wird über /bin/zsh ausgeführt. Unter Windows tarnt er sich als wt.exe (Windows Terminal) in %PROGRAMDATA% und nutzt einen VBScript-Dropper. Unter Linux wird ein Python-RAT nach /tmp/ld.py heruntergeladen und per nohup im Hintergrund gestartet.

Phase 4 – Spurenbeseitigung: Das postinstall-Skript löscht sich selbst und ersetzt die eigene package.json durch die saubere Version 4.2.0. Ein anschließendes npm list zeigt Version 4.2.0 an. Ein npm audit findet keine Auffälligkeiten. Die Infektion ist aktiv, aber unsichtbar.

Einmal installiert, hat der RAT Zugriff auf alles, was auf dem kompromittierten System liegt: AWS-Credentials, OpenAI-API-Keys, GitHub-Tokens, SSH-Schlüssel, .env-Dateien mit Datenbank-Passwörtern. In CI/CD-Umgebungen sind die Auswirkungen potenziell noch gravierender: Dort liegen häufig Deployment-Credentials, Signing-Keys und Zugang zu Produktivsystemen. Ein kompromittierter Build-Server kann zum Einfallstor für die gesamte Infrastruktur werden.

StepSecurity entdeckte den Angriff über ihren AI Package Analyst und das Laufzeit-Monitoring-Tool Harden-Runner in instrumentierten GitHub-Actions-Pipelines. Das Tool registriert ausgehende Netzwerkverbindungen während npm install und schlug Alarm, als ein unbekannter C2-Server kontaktiert wurde.

„Der wichtigste Sicherheitstipp lautet seit Jahren: Halte deine Pakete aktuell. Seit Kurzem fühlt es sich so an, als wäre genau das der schnellste Weg, kompromittiert zu werden.“
– Anmerkung der Redaktion

Warum dieser Angriff eine neue Qualität hat

Supply-Chain-Angriffe auf npm sind nicht neu. Der event-stream-Vorfall 2018 blieb monatelang unentdeckt und zielte auf Krypto-Wallets. Die Kompromittierung von ua-parser-js 2021 betraf ein Paket mit sieben Millionen Downloads pro Woche und verteilte Credential-Stealer. Die Sabotage von colors.js 2022 war eine politische Protestaktion des Maintainers selbst. Jeder dieser Vorfälle hat das Ökosystem erschüttert – und dennoch markiert der Axios-Angriff eine Eskalation.

Die Zielgröße ist beispiellos: Axios gehört zu den zehn meistgenutzten npm-Paketen überhaupt. Die Blast-Radius einer erfolgreichen Kompromittierung betrifft potenziell Hunderttausende Projekte und CI/CD-Pipelines weltweit.

Die Raffinesse übersteigt frühere Angriffe deutlich. Statt Schadcode direkt in den Quellcode zu schreiben, nutzte der Angreifer eine gestaffelte Dependency-Injection mit zeitversetzter Aktivierung und automatischer Spurenbeseitigung. Nach der Installation sah das System sauber aus – eine aktive Tarnung, die über passives Verstecken weit hinausgeht. StepSecurity registrierte den ersten C2-Kontakt innerhalb von zwei Sekunden nach einem npm install auf einem instrumentierten Runner – ohne dieses automatisierte Monitoring wäre der Angriff möglicherweise deutlich länger unentdeckt geblieben.

Der Vergleich mit früheren npm-Vorfällen verdeutlicht die Eskalation: Beim event-stream-Angriff 2018 übernahm ein Angreifer ein verwaistes Paket durch Social Engineering und platzierte über Monate hinweg Schadcode, der auf Bitcoin-Wallets zielte. Bei ua-parser-js 2021 wurde der Maintainer-Account gekapert und ein Credential-Stealer verteilt – ähnlich wie beim Axios-Angriff, aber ohne die mehrstufige Verschleierung und ohne plattformübergreifende Payloads. Die colors.js-Sabotage 2022 war eine bewusste Protestaktion des Maintainers, keine externe Kompromittierung.

Hinzu kommt die Attribution: Microsoft Threat Intelligence ordnet den Angriff der Gruppe Sapphire Sleet zu, Google Threat Intelligence Group der Gruppe UNC1069. Beide Bezeichnungen verweisen auf nordkoreanische Akteure mit finanzieller Motivation. Elastic Security Labs identifizierte Überlappungen des macOS-Binaries mit WAVESHAPER, einem bekannten nordkoreanischen Backdoor. Sollte sich diese Einordnung bestätigen, wäre es der erste dokumentierte Fall, in dem ein staatlicher Akteur ein Top-100-npm-Paket kompromittiert hat.

Was IT-Teams jetzt tun müssen

Die Kompromittierung betrifft nicht nur JavaScript-Entwickler. Jede Organisation, die Axios in ihren Projekten oder CI/CD-Pipelines einsetzt, sollte folgende Maßnahmen priorisieren:

1. Versionscheck durchführen: Alle package.json-Dateien und Lock-Dateien auf axios@1.14.1 oder axios@0.30.4 prüfen. Sofort auf 1.14.0 bzw. 0.30.3 downgraden.
2. node_modules scannen: Nach dem Paket plain-crypto-js suchen. Falls vorhanden: System als kompromittiert behandeln.
3. RAT-Artefakte prüfen: Unter macOS nach /Library/Caches/com.apple.act.mond suchen, unter Windows nach %PROGRAMDATA%/wt.exe, unter Linux nach /tmp/ld.py.
4. Credentials rotieren: Alle API-Keys, Tokens und Zugangsdaten auf betroffenen Systemen sofort erneuern – AWS, OpenAI, GitHub, .env-Dateien.
5. C2 blockieren: IP 142.11.206.73 und Domain sfrclak.com auf dem Netzwerkperimeter sperren.
6. CI/CD absichern: npm ci –ignore-scripts als Standard einführen. Minimum-Release-Age-Policies aktivieren, damit frisch veröffentlichte Versionen nicht automatisch installiert werden.

Die strukturelle Schwachstelle bleibt

Der Axios-Vorfall legt ein grundlegendes Problem des npm-Ökosystems offen: Ein einzelner Account mit einem gültigen Publish-Token kann Schadcode an Millionen von Systemen verteilen. npm hat mit Trusted Publishers und OIDC-basierter Authentifizierung Fortschritte gemacht – doch der Angreifer hat genau diesen Mechanismus umgangen, indem er den Maintainer-Account selbst übernahm.

Für CISOs und IT-Security-Teams ergibt sich eine klare Priorität: Software-Supply-Chain-Security muss denselben Stellenwert bekommen wie Netzwerk- oder Endpoint-Security. Automatisiertes Dependency-Monitoring, Runtime-Analyse in CI/CD-Pipelines und konsequente Policies für Third-Party-Pakete sind keine Nice-to-haves mehr.

Konkret bedeutet das: Jede Organisation braucht eine aktuelle Software Bill of Materials (SBOM), automatisierte Alerts bei ungewöhnlichen Dependency-Änderungen und eine klare Policy, wie schnell neue Paketversionen in Produktivsysteme gelangen dürfen. Lock-Dateien konsequent einzusetzen, postinstall-Skripte in CI/CD standardmäßig zu deaktivieren und Minimum-Release-Age-Policies zu konfigurieren sind drei Maßnahmen, die den Großteil dieser Angriffsfläche eliminieren. Der nächste Angriff wird nicht auf Axios zielen – aber er wird dieselbe Mechanik nutzen.

Häufige Fragen

Bin ich betroffen, wenn ich Axios nutze?

Nur wenn Sie Version 1.14.1 oder 0.30.4 installiert haben. Alle anderen Versionen sind nicht betroffen. Prüfen Sie Ihre package.json und Ihre Lock-Dateien (package-lock.json, yarn.lock, pnpm-lock.yaml).

Reicht es, die betroffene Axios-Version zu deinstallieren?

Nein. Wenn der RAT bereits ausgeführt wurde, hat er sich in Systempfade kopiert und das postinstall-Skript gelöscht. Ein Downgrade von Axios allein beseitigt den Trojaner nicht. Behandeln Sie das System als kompromittiert und rotieren Sie alle Credentials.

Wie wurde der Maintainer-Account kompromittiert?

Der genaue Angriffsvektor ist Stand April 2026 nicht öffentlich bestätigt. Bekannt ist, dass die registrierte E-Mail-Adresse des npm-Accounts jasonsaayman gegen eine Proton-Mail-Adresse ausgetauscht wurde und die Releases die reguläre GitHub-Actions-Pipeline umgingen.

Gibt es eine CVE-Nummer für diesen Vorfall?

Stand April 2026 wurde keine CVE zugewiesen. Mehrere Sicherheitsunternehmen haben den Vorfall dokumentiert, eine formale CVE-Vergabe steht aber noch aus.

Warum hat npm die Schadversionen nicht schneller erkannt?

npm führt keine automatisierte Verhaltensanalyse bei der Veröffentlichung durch. Pakete werden primär auf bekannte Malware-Signaturen geprüft. Ein postinstall-Skript, das einen externen Server kontaktiert, ist technisch nicht ungewöhnlich – viele legitime Pakete nutzen ähnliche Mechanismen für Setup-Schritte. Die Erkennung erfolgte durch externes Monitoring, nicht durch npm-eigene Schutzmechanismen.

Was kann ich tun, um Supply-Chain-Angriffe generell einzudämmen?

Nutzen Sie Lock-Dateien konsequent, führen Sie npm ci statt npm install in CI/CD-Pipelines aus, aktivieren Sie –ignore-scripts für nicht-vertrauenswürdige Pakete und setzen Sie auf Runtime-Monitoring-Tools. Eine Minimum-Release-Age-Policy verhindert, dass frisch veröffentlichte Versionen automatisch installiert werden. Ergänzend sollten Teams eine Software Bill of Materials (SBOM) pflegen und bei Dependency-Änderungen automatisierte Alerts einrichten.

Quelle Titelbild: KI-generiertes Stimmungsbild (FLUX.2) – keine Produktabbildung

Hier schreibt Benedikt Langer für Sie

Mehr Artikel vom Autor Benedikt Langer