Axios-npm-Paket kompromittiert: Supply-Chain-Angriff verbreitet plattformübergreifenden RAT

Am 31. März 2026 wurden zwei bösartige Versionen von axios, dem äußerst beliebten JavaScript-HTTP-Client mit über 100 Millionen Downloads pro Woche, kurzzeitig über ein kompromittiertes Maintainer-Konto auf npm veröffentlicht. Die Pakete enthielten eine versteckte Abhängigkeit, die auf jedem Rechner, auf dem während eines zweistündigen Zeitfensters npm install (oder ein entsprechender Befehl in einem anderen Paketmanager wie Bun) ausgeführt wurde, einen plattformübergreifenden Remote-Access-Trojaner (RAT) installierte.

Die bösartigen Versionen (1.14.1 und 0.30.4) wurden bis 03:29 UTC von npm entfernt. Während sie verfügbar waren, konnten jedoch alle kompromittiert worden sein, deren CI/CD-Pipeline, Entwicklungsumgebung oder Build-System eine frische Installation abgerufen hatte – ohne jemals eine Zeile Axios-Code zu verwenden.

Kurzfassung

So wurde der Angriff durchgeführt

Hier handelt es sich weder um ein Paket mit Tippfehler im Namen noch um eine unbemerkte bösartige Abhängigkeit in einem Build. Der Angreifer hatte (oder erlangte) direkten Veröffentlichungszugriff auf das offizielle axios-Paket auf npm, vermutlich durch die Kompromittierung eines Maintainer-Kontos. Laut einem Mitwirkenden im offiziellen GitHub-Issue-Thread gehörte das mutmaßlich kompromittierte Konto dem Maintainer @jasonsaayman. Dessen Repository-Berechtigungen waren umfassender als die anderer Mitwirkender, was eine schnelle Behebung erschwerte.

Der Angreifer änderte keine Axios-Quelldateien direkt. Stattdessen fügte er den vorbereiteten Schadcode als Abhängigkeit plain-crypto-js@4.2.1 in die package.json der neuen axios-Versionen ein. Das Paket plain-crypto-js wurde eigens für diesen Angriff entwickelt: Eine frühere „saubere“ Version (4.2.0) war 18 Stunden zuvor veröffentlicht worden – wahrscheinlich, um eine kurze Historie in der Registry aufzubauen. Version 4.2.1 enthielt die Schadsoftware.

Wenn ein Entwickler oder CI-System npm install axios@1.14.1 ausführt, löst npm den Abhängigkeitsbaum auf, lädt plain-crypto-js@4.2.1 herunter und führt automatisch dessen postinstall-Hook aus: node setup.js. Mit dieser Skriptausführung beginnt die Kompromittierung.

Der Dropper: doppelt verschleiert und selbstlöschend

Der Postinstall-Dropper setup.js nutzt zwei Verschleierungsebenen, um statische Analysen zu umgehen:

1. Umgekehrte Base64-Kodierung mit ersetztem Füllzeichen

2. XOR-Chiffre mit dem Schlüssel OrDeR_7077 und dem konstanten Wert 333

Nach der Entschleierung ermittelt das Skript das Host-Betriebssystem über os.platform() und kontaktiert den C2-Server unter sfrclak[.]com:8000 (IP: 142.11.206.73), um eine für die jeweilige Plattform geeignete Schadsoftware der zweiten Stufe herunterzuladen.

Nach der Ausführung verwischt die Malware ihre Spuren: Sie löscht setup.js, entfernt die package.json mit dem postinstall-Hook und ersetzt sie durch eine unverfängliche package.md, die in package.json umbenannt wird. Wenn Sie anschließend node_modules/plain-crypto-js untersuchen, finden Sie keine offensichtlichen Hinweise darauf, dass dort jemals ein Postinstall-Skript vorhanden war.

Plattformspezifische Schadsoftware

Die Schadsoftware der zweiten Stufe ist speziell auf die jeweilige Plattform zugeschnitten.

macOS

Ein AppleScript lädt eine Binärdatei nach /Library/Caches/com.apple.act.mond herunter. Der Dateiname imitiert absichtlich das Namensschema eines Apple-Hintergrunddienstes, um nicht aufzufallen. Nach der Installation kann der RAT:

• Eine eindeutige 16-stellige Opfer-ID generieren

• Das System erfassen: Hostname, Benutzername, macOS-Version, Start- und Installationszeit, CPU-Architektur (mac_arm oder mac_x64) und laufende Prozesse

• Alle 60 Sekunden den C2-Server kontaktieren und dafür einen gefälschten IE8/Windows-XP-User-Agent-String verwenden

• Akzeptiert vier Befehle des Angreifers:

  • peinject: Empfängt eine Base64-kodierte Binärdatei vom C2-Server, dekodiert sie, schreibt sie in eine versteckte temporäre Datei (z. B. /private/tmp/.XXXXXX), signiert den Code ad hoc mit codesign --force --deep --sign - , um Gatekeeper zu umgehen, und führt sie aus

  • runscript: Führt beliebige Shell-Befehle über /bin/sh oder AppleScript-Dateien über osascript aus

  • rundir: Listet Dateisystem-Metadaten aus /Applications, ~/Library und ~/Application Support auf

  • kill: Beendet den RAT-Prozess

Windows

Ein VBScript-Downloader kopiert die PowerShell-Binärdatei nach %PROGRAMDATA%\wt.exe (getarnt als Windows Terminal) und führt einen versteckten PowerShell-RAT mit Flags zur Umgehung der Ausführungsrichtlinie aus.

Linux

Ein Python-RAT wird nach /tmp/ld.py heruntergeladen und mit nohup python3 als verwaister Hintergrundprozess gestartet. Dadurch wird er von der Terminal-Sitzung getrennt, die ihn gestartet hat.

Weitere kompromittierte Pakete

Bei zwei weiteren Paketen wurde festgestellt, dass sie die bösartige Abhängigkeit plain-crypto-js enthielten:

• @qqbrowser/openclaw-qbot@0.0.130 – enthält ein manipuliertes axios@1.14.1 mit der eingeschleusten Abhängigkeit (SNYK-JS-QQBROWSEROPENCLAWQBOT-15850776)

• @shadanai/openclaw (Versionen 2026.3.31-1, 2026.3.31-2) – enthält plain-crypto-js direkt (SNYK-JS-SHADANAIOPENCLAW-15850775)

Diese weiteren Pakete deuten entweder auf eine koordinierte Angreifer-Infrastruktur hin oder darauf, dass plain-crypto-js aktiv in verwandten Kampagnen eingesetzt wurde.

Wer tatsächlich gefährdet ist

Das dreistündige Veröffentlichungsfenster (00:21 bis 03:29 UTC) ist entscheidend. Am größten ist das Risiko für:

• CI/CD-Pipelines, die Abhängigkeitsversionen nicht festschreiben und regelmäßig oder bei jedem Commit npm install ausführen – insbesondere nachts oder in den frühen Morgenstunden (UTC).

• Entwickler, die in diesem Zeitraum npm install oder npm update ausgeführt und dabei zufällig die betroffenen Versionen geladen haben.

• Projekte mit Abhängigkeit von @qqbrowser/openclaw-qbot oder @shadanai/openclaw, deren Gefährdung nicht vom Zeitfenster abhängt.

Wenn Ihr Lockfile (package-lock.json oder yarn.lock) bereits vor der Veröffentlichung der bösartigen Versionen eingecheckt wurde und bei der Installation nicht aktualisiert wurde, waren Sie nicht betroffen. Lockfiles sind hier Ihre erste Verteidigungslinie.

Die bösartigen Versionen wurden aus der npm-Registry entfernt. Wer sie jedoch während des Zeitfensters installiert hat, sollte von einer vollständigen Systemkompromittierung ausgehen: Der RAT war aktiv, sendete Signale an den C2-Server und konnte beliebige weitere Schadsoftware ausführen.

Behebung mit Snyk und Überprüfung Ihrer Gefährdung

Wenn Sie Snyk verwenden, weisen Sie die verschiedenen Snyk-Integrationen auf alle Projekte hin, die die kompromittierte und bösartige Version der Abhängigkeit axios enthalten – ob über die Snyk CLI, die Snyk-App-Integration oder auf anderem Weg.

Die Snyk-Datenbank enthält Einträge sowohl für SNYK-JS-AXIOS-15850650 als auch für SNYK-JS-PLAINCRYPTOJS-15850652. Daher kennzeichnet snyk test die betroffenen Versionen und die bösartige transitive Abhängigkeit.

Wenn Sie außerdem den Enterprise-Plan nutzen, sehen Sie in der Anwendung einen Zero-Day-Bericht – ähnlich wie bei früheren Zero-Day-Sicherheitsvorfällen wie LiteLLM, Shai-Hulud und anderen. So erhalten Sie einen systemweiten Überblick und können betroffene Projekte und Repositories mit der anfälligen axios-Abhängigkeit einfach finden und genau bestimmen:

Wenn Sie Snyk noch nicht verwenden: Es gibt einen kostenlosen Tarif, mit dem Sie schnell loslegen und Ihre Umgebung auf eine mögliche axios-Kompromittierung oder andere Sicherheitsprobleme überprüfen können:

# Install Snyk CLI if you haven't already
npm install -g snyk

# Authenticate
snyk auth

# Test your project
snyk test

Für Bun-Nutzer: Snyk-Workaround (zum Zeitpunkt der Veröffentlichung ist die native Unterstützung für bun.lock in der Snyk CLI eingeschränkt):

Als empfohlenen Workaround können Sie mit dem integrierten Flag -y von Bun ein mit yarn.lock kompatibles Lockfile erstellen, das Snyk verarbeiten kann:

# 1. Regenerate lockfile in yarn.lock format
bun install -y

# 2. Run snyk against the generated yarn.lock
snyk test --file=yarn.lock

Alternativ können Sie die folgenden Schritte ausführen, um festzustellen, ob Sie von der axios-Kompromittierung betroffen sind:

Schritt 1: Prüfen Sie Ihr Lockfile auf betroffene Versionen

# Check for axios 1.14.1 or 0.30.4
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# Or with yarn
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'

Schritt 2: Prüfen Sie, ob die bösartige Abhängigkeit vorhanden ist

# Look for plain-crypto-js in your dependency tree
npm ls plain-crypto-js

# Or search node_modules directly
find node_modules -name "plain-crypto-js" -type d

Schritt 3: Prüfen Sie auf Installationen der bösartigen axios-Abhängigkeit zur Laufzeit mit Bun

Wenn Sie Bun verwenden, prüfen Sie Ihre bun.lock-Datei (Text-Lockfile, Bun v1.1+):

grep -E 'axios' bun.lock | grep -E '1\.14\.1|0\.30\.4'

Prüfen Sie außerdem, ob die bösartige transitive Abhängigkeit vorhanden ist:

grep 'plain-crypto-js' bun.lock

Hinweis: Ältere Bun-Versionen erstellen eine binäre bun.lockb-Datei. Konvertieren Sie sie zuerst, um sie zu untersuchen:

> bun bun.lockb  # prints human-readable output to stdout
> bun bun.lockb | grep -E 'axios.*1\.14\.1|axios.*0\.30\.4'
> bun bun.lockb | grep 'plain-crypto-js'

Schritt 4: Prüfen Sie kompromittierte Systeme auf IoCs

Wenn Sie vermuten, dass auf einem Rechner im betroffenen Zeitraum npm install ausgeführt wurde, suchen Sie nach folgenden Indikatoren:

Weitere Empfehlungen zur Behebung für npm-Paketmanager

Wenn Sie nicht betroffen sind (vorsorgliche Maßnahmen):

1. Fixieren Sie axios in Ihrer package.json auf eine bekanntermaßen sichere Version. Alle Versionen außer 1.14.1 und 0.30.4 sind unbedenklich.

2. Checken Sie Ihr Lockfile ein und stellen Sie sicher, dass CI npm ci (nicht npm install) verwendet, um die Integrität des Lockfiles durchzusetzen.

3. Fügen Sie plain-crypto-js in Ihrem Paketmanager oder Ihren Sicherheitstools einer Sperrliste hinzu.

Erwägen Sie, --ignore-scripts für npm-Installationen in CI-Umgebungen zu aktivieren, in denen Lifecycle-Hooks nicht benötigt werden:

npm ci --ignore-scripts

Dadurch werden Postinstall-Skripte vollständig an der Ausführung gehindert und dieser Angriffsweg wäre blockiert worden. Beachten Sie, dass dadurch Pakete beeinträchtigt werden können, die legitimerweise Schritte nach der Installation benötigen (zum Beispiel native Add-ons).

Erwägen Sie außerdem, das Open-Source-Projekt npq zu nutzen und in Ihren Entwicklerteams einzuführen. Es führt vor der Installation von Abhängigkeiten Sicherheits- und Statusprüfungen durch.

Abschließend empfiehlt es sich, diese öffentlich zusammengestellten Best Practices für npm-Sicherheit zu prüfen und zu berücksichtigen.

Wenn Sie betroffen sind (von einer Kompromittierung ausgehen):

1. Sofort eindämmen: Isolieren Sie alle Systeme, auf denen im betroffenen Zeitraum npm install ausgeführt wurde.

2. Alle Geheimnisse ändern: Gehen Sie davon aus, dass alle Zugangsdaten auf dem betroffenen Rechner kompromittiert wurden – API-Schlüssel, SSH-Schlüssel, Cloud-Anmeldedaten, npm-Token und GitHub-Token. Ändern Sie sie nicht einfach vor Ort, sondern widerrufen Sie sie und stellen Sie neue aus.

3. Auf laterale Bewegungen prüfen: Prüfen Sie Protokolle auf ausgehende Verbindungen zu sfrclak[.]com oder 142.11.206.73. War der RAT aktiv, konnte der Angreifer beliebigen Code ausführen und möglicherweise weitere Systeme erkunden oder Daten exfiltrieren.

4. Umgebungen neu aufsetzen: Versuchen Sie nicht, kompromittierte Systeme zu bereinigen. Setzen Sie sie anhand eines nachweislich sauberen Snapshots oder Basisimages neu auf.

5. CI-Pipelines überprüfen: Prüfen Sie die Build-Protokolle für den Zeitraum am 31. März 2026 (UTC), um festzustellen, welche Pipelines die betroffenen Versionen installiert haben.

Das große Ganze: Sicherheit von Maintainer-Konten

Dieser Angriff folgt einem inzwischen bekannten Muster: Ein legitimes Maintainer-Konto wird kompromittiert, eine bösartige Version eines vertrauenswürdigen Pakets veröffentlicht und das implizite Vertrauen des Ökosystems in registrierte Pakete ausgenutzt. Dieses Vorgehen wurde bereits gegen ESLint's Prettier plugin, gegen mehrere Pakete eines produktiven Entwicklers, die durch Phishing kompromittiert wurden und bei der Shai-Hulud-Kampagne eingesetzt, bei der über 600 Pakete kompromittiert wurden.

Besonders bedeutsam ist das Ausmaß: Bei 100 Millionen Downloads pro Woche bedeutet selbst ein zweistündiges Zeitfenster mit Schadsoftware ein enormes potenzielles Schadensausmaß. Der Angreifer zeigte zudem beträchtliche operative Raffinesse: Er stellte die schädliche Abhängigkeit im Voraus bereit, nutzte einen „sauberen“ Versionsverlauf, verschleierte den Dropper doppelt, erstellte plattformspezifische RATs und implementierte eine Selbstlöschung zur Spurenbeseitigung. Das war kein opportunistischer Angriff.

Für Unternehmen, die in großem Umfang auf Open Source setzen, lautet die Lehre nicht, npm nicht mehr zu verwenden oder allen Abhängigkeiten zu misstrauen. Entscheidend ist vielmehr, zu verstehen, welche Supply-Chain-Sicherheitsmaßnahmen diesen Vorfall verhindert hätten: die Durchsetzung von Lockfiles, die Überprüfung von Postinstall-Skripten und die Laufzeitüberwachung auf unerwartete Prozessstarts oder ausgehende Netzwerkverbindungen aus Build-Umgebungen. Snyks Leitfaden zur Verhinderung von npm-Supply-Chain-Angriffen und die Sicherheitsaspekte bei Lockfiles sind im Zusammenhang mit diesem Vorfall eine erneute Lektüre wert.

Wenn Sie die Angriffsklasse konzeptionell verstehen möchten, bietet Snyk Learn eine spezielle Lektion zur Kompromittierung legitimer Pakete, in der Angriffsmuster und Schutzmaßnahmen erläutert werden.

Zeitachse