Axios npm Supply-Chain-Angriff: Maintainer-Konto gekapert, RAT-Malware auf drei Plattformen verteilt

Am 31. März 2026 wurde das npm-Konto des Hauptentwicklers von Axios übernommen. Innerhalb von 39 Minuten wurden zwei manipulierte Versionen veröffentlicht, die einen vollwertigen Remote-Access-Trojaner auf macOS, Windows und Linux installieren. Bei über 100 Millionen Downloads pro Woche ist das einer der schwersten Supply-Chain-Angriffe auf das npm-Ökosystem.

Was ist passiert?

Axios ist der meistgenutzte HTTP-Client im JavaScript-Ökosystem. Nahezu jedes Node.js-Projekt, jede React-App und jedes Enterprise-Backend, das HTTP-Requests macht, setzt Axios ein. Am 31. März 2026 gelang es Angreifern, das npm-Konto des Lead-Maintainers Jason Saayman zu übernehmen.

Die Angreifer änderten die hinterlegte E-Mail-Adresse auf ifstap@proton.me und veröffentlichten mit einem gestohlenen npm-Token zwei neue Versionen — ohne dass ein einziger Commit, Tag oder Release im offiziellen GitHub-Repository existiert.

Beide Versionen wurden inzwischen von npm entfernt. Wer sie in dem kurzen Zeitfenster installiert hat, muss davon ausgehen, dass das System kompromittiert ist.

Warum ist das so gefährlich?

Der Angriff nutzt einen Mechanismus, der bei den meisten JavaScript-Projekten Standard ist: automatische Versionsauflösung. Wer in seiner package.json Axios mit ^1.14.0 oder ^0.30.0 referenziert — also mit dem üblichen Caret-Prefix — bekommt bei npm install automatisch die neueste kompatible Version. In diesem Fall die mit der Malware.

Das bedeutet: Jedes CI/CD-System, jeder Entwickler, jeder automatisierte Build, der in dem Zeitfenster lief, hat potenziell die kompromittierte Version gezogen. Und das bei einem Paket mit 400 Millionen monatlichen Downloads.

Was macht die Malware konkret?

Die einzige Änderung in den kompromittierten Axios-Versionen war das Hinzufügen von plain-crypto-js@^4.2.1 als Dependency. Dieses Paket wird nirgendwo im Axios-Quellcode importiert — es existiert ausschließlich, um einen postinstall-Hook auszuführen.

Schritt 1: Dropper-Ausführung

Nach npm install wird automatisch die Datei setup.js ausgeführt. Diese enthält 18 verschleierte Strings, die über eine zweistufige Verschlüsselung versteckt sind:

• Schicht 1: Umgekehrtes Base64 mit Underscore als Padding-Zeichen
• Schicht 2: XOR-Cipher mit dem Schlüssel OrDeR_7077 und der Konstante 333

Dieses Verfahren ist kein Minification und kein Codeschutz — es ist gezielt darauf ausgelegt, Malware-Scanner zu umgehen.

Schritt 2: Plattform-spezifische Payloads

Der Dropper erkennt das Betriebssystem und lädt eine maßgeschneiderte Payload vom Command-and-Control-Server sfrclak[.]com:8000:

macOS: Über AppleScript wird eine Binärdatei nach /Library/Caches/com.apple.act.mond heruntergeladen — bewusst als Apple-Systemdaemon getarnt. Es handelt sich um einen vollwertigen RAT (Remote Access Trojan) in C++, der Systeminformationen sammelt, Prozesse auflistet, beliebige Befehle ausführt und mit dem C2-Server kommuniziert.

Windows: PowerShell wird nach %PROGRAMDATA%\wt.exe kopiert — getarnt als Windows Terminal, um EDR-Erkennung zu umgehen. Ein VBScript startet dann verdeckt ein heruntergeladenes PowerShell-Script mit -w hidden -ep bypass.

Linux: Ein Python-Script wird nach /tmp/ld.py heruntergeladen und im Hintergrund mit nohup python3 gestartet.

Schritt 3: Spurenverwischung

Nach der Ausführung löscht sich setup.js selbst und ersetzt die eigene package.json durch eine saubere Version. Eine nachträgliche Inspektion von node_modules zeigt dadurch keine Auffälligkeiten — die Malware ist bereits aktiv, aber unsichtbar.

Bin ich betroffen? So prüfen Sie es

1. Installierte Axios-Version prüfen

npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"
grep -A1 '"axios"' package-lock.json | grep -E "1\.14\.1|0\.30\.4"

2. Dropper-Paket suchen

ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENZIELL BETROFFEN"

3. RAT-Artefakte auf dem System prüfen

# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null && echo "KOMPROMITTIERT"

# Windows (CMD)
dir "%PROGRAMDATA%\wt.exe" 2>nul && echo KOMPROMITTIERT

# Linux
ls -la /tmp/ld.py 2>/dev/null && echo "KOMPROMITTIERT"

Sofortmaßnahmen bei Betroffenheit

1. Auf sichere Version pinnen:

   npm install axios@1.14.0   # für 1.x-Nutzer
   npm install axios@0.30.3   # für 0.x-Nutzer

2. Version-Overrides setzen (verhindert transitive Auflösung):

   {
     "dependencies": { "axios": "1.14.0" },
     "overrides": { "axios": "1.14.0" },
     "resolutions": { "axios": "1.14.0" }
   }

3. Dropper-Paket entfernen:

   rm -rf node_modules/plain-crypto-js
   npm install --ignore-scripts

4. Wenn RAT-Artefakte gefunden: Das System nicht bereinigen, sondern komplett neu aufsetzen von einem bekannt sicheren Zustand.
5. Alle Zugangsdaten rotieren: npm-Tokens, SSH-Keys, AWS Access Keys, CI/CD-Secrets, Umgebungsvariablen — alles, worauf das kompromittierte System Zugriff hatte.
6. CI/CD-Pipeline-Logs prüfen: Alle Builds, die im Angriffszeitraum gelaufen sind, auf die betroffenen Versionen untersuchen. Injizierte Secrets rotieren.

Indicators of Compromise (IOCs)

Was lernen wir daraus?

Dieser Angriff zeigt ein strukturelles Problem im npm-Ökosystem: Ein einzelnes kompromittiertes Maintainer-Konto reicht aus, um Millionen von Projekten zu gefährden. Konkret:

• Long-lived npm Tokens sind ein Risiko. Axios nutzte zwar OIDC Trusted Publishing über GitHub Actions, aber ein alter npm-Token existierte parallel — und damit die Möglichkeit, am offiziellen Release-Prozess vorbei zu veröffentlichen.
• Caret-Ranges (^) sind ein Einfallstor. Die Standardkonfiguration in package.json zieht automatisch neue Patch-Versionen. Exakte Versionspins und Lock-Files sind kein Nice-to-have, sondern Pflicht.
• postinstall-Hooks sind mächtig. Ein einzelnes "postinstall": "node setup.js" reicht, um beliebigen Code auf dem Entwicklerrechner auszuführen — automatisch, ohne Bestätigung.
• Selbstlöschende Malware erschwert Forensik. Der Dropper entfernt sich nach der Ausführung. Wer nicht aktiv loggt, bemerkt den Angriff möglicherweise nie.

Empfehlungen für Unternehmen

1. Lock-Files versionieren und in CI/CD erzwingen. Nutzen Sie npm ci statt npm install in Pipelines. Das stellt sicher, dass exakt die Versionen aus dem Lock-File installiert werden.
2. --ignore-scripts als Default. Deaktivieren Sie postinstall-Hooks in CI/CD und aktivieren Sie sie nur gezielt für bekannte Pakete.
3. Dependency-Monitoring einsetzen. Tools wie Socket, Snyk oder Aikido erkennen schädliche Pakete oft innerhalb von Minuten.
4. Minimum Release Age. Neue Paketversionen erst nach einer Karenzzeit (z.B. 48 Stunden) in Produktion übernehmen. Tools wie Aikido Safe Chain erzwingen das automatisch.
5. npm-Accounts absichern. Maintainer sollten 2FA aktivieren, langlebige Tokens vermeiden und ausschließlich über Trusted Publishing (OIDC) veröffentlichen.
6. Regelmäßige Dependency-Audits. npm audit allein reicht nicht — es erkennt nur bekannte CVEs, keine frisch veröffentlichte Malware.