Axios Schwachstelle? Axios npm kompromittiert: IOCs und Sofortmaßnahmen

Der Axios npm compromise ist nicht deshalb relevant, weil irgendein Nischenpaket betroffen war. Es geht um Axios, also um eine Bibliothek, die in unzähligen JavaScript-Projekten steckt und in vielen Teams als völlig normaler Baustein mitläuft. Am 31. März 2026 wurden die Versionen axios@1.14.1 und axios@0.30.4 kompromittiert veröffentlicht. Dabei wurde die bösartige Abhängigkeit plain-crypto-js@4.2.1 nachgeladen, deren postinstall-Hook eine plattformübergreifende RAT ausführen konnte.

Viele suchen gerade nach Axios Schwachstelle, Axios Sicherheitslücke oder Axios npm. Das ist verständlich, trifft den Kern aber nur teilweise. Nach aktuellem Stand handelt es sich nicht in erster Linie um einen klassischen Fehler im Axios-Code, sondern um einen kompromittierten npm-Release mit bösartiger Zusatzabhängigkeit und nachgelagerter Malware.

Für Unternehmen ist vor allem eines wichtig: Das Thema endet nicht bei Produktionssystemen. Gefährdet sind auch Entwickler-Laptops, Self-Hosted-Runner, Build-Container oder Preview-Umgebungen, wenn dort im betroffenen Zeitfenster ein frischer Install gelaufen ist. Genau diese Systeme werden in der ersten Bewertung oft übersehen.

Was genau ist passiert?

Nach aktuellem Stand wurde ein Maintainer-Zugang kompromittiert und der übliche Release-Pfad umgangen. Datadog beschreibt, dass axios@1.14.0 noch regulär über GitHub Actions OIDC Trusted Publishing veröffentlicht wurde. Die kompromittierte Version erschien dagegen direkt aus einer fremden npm-Session. Auffällig war außerdem eine geänderte Maintainer-E-Mail in den Registry-Metadaten.

Besonders heikel ist, dass die Kette offenbar nicht improvisiert war. Trend Micro beschreibt plain-crypto-js@4.2.0 als eher unauffällige Vorstufe und plain-crypto-js@4.2.1 als eigentliche Payload. Elastic zeigt außerdem, dass sowohl der latest- als auch der legacy-Pfad getroffen wurden. Anders gesagt: Die Angreifer wollten nicht nur moderne Setups treffen, sondern auch ältere Installationspfade mitnehmen.

Die Malware verhielt sich je nach Plattform unterschiedlich: auf macOS als natives Binary, auf Windows mit PowerShell- und Persistenzartefakten, auf Linux als Python-Skript. Danach beaconten die Systeme gegen sfrclak[.]com:8000. Zusätzlich wurden Spuren verwischt, indem Dateien entfernt und eine saubere package.json zurückkopiert wurde.

Axios npm betroffen? So prüfen Sie Lockfiles, Systeme und Build-Pfade

Die wichtigste Frage lautet nicht nur: Nutzen wir Axios? Sondern vor allem: Hat irgendein System die kompromittierten Versionen installiert? Huntress weist ausdrücklich darauf hin, dass gerade Entwicklerrechner, Self-Hosted-Runner, Build-Server und kurzlebige Umgebungen in die Prüfung gehören.

npm ls axios plain-crypto-js
grep -R "plain-crypto-js" package-lock.json yarn.lock pnpm-lock.yaml bun.lock 2>/dev/null
find node_modules -type d -name "plain-crypto-js"
grep -R "axios@1.14.1\|axios@0.30.4" .npm _logs package-lock.json 2>/dev/null
ls -la /tmp/ld.py
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null

npm ls axios plain-crypto-js
Get-ChildItem -Recurse -File | Select-String -Pattern "plain-crypto-js|axios@1.14.1|axios@0.30.4"
Test-Path "$env:PROGRAMDATA\wt.exe"
Test-Path "$env:PROGRAMDATA\system.bat"
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v MicrosoftUpdate
Get-ChildItem $env:TEMP -Filter "6202033*" -Force

Wichtige IOCs zum Axios npm compromise

Für Detection, Threat Hunting und Incident Response lohnen sich vor allem vier IOC-Gruppen: betroffene Pakete, Netzwerkziele, Host-Artefakte und Persistenzspuren. Huntress, Snyk und Google nennen hier weitgehend konsistente Indicators, besonders rund um sfrclak[.]com, 142.11.206.73 und plattformspezifische Dateien.

Sofortmaßnahmen: Was Unternehmen jetzt tun sollten

Bei einem Treffer reicht es nicht, einfach wieder auf eine saubere Axios-Version zu wechseln. Mehrere Incident-Response-Analysen empfehlen ausdrücklich, betroffene Systeme als kompromittiert zu behandeln und entsprechend konsequent vorzugehen.

Huntress meldete zwar, dass die konkret beobachtete C2-Infrastruktur später offline war. Das ist aber keine Entwarnung. Bereits gestohlene Secrets, manipulierte Artefakte oder nachgeladene Payloads verschwinden dadurch nicht automatisch.

Ist das eine Axios Schwachstelle oder ein npm Supply-Chain-Angriff?

Der Vorfall zeigt ziemlich klar, wo das Grundproblem moderner Softwareentwicklung liegt: Vertrauen in populäre Pakete ersetzt keine Supply-Chain-Kontrollen. Gerade bei einem Paket wie Axios gehen viele Teams stillschweigend davon aus, dass ein Update schon sicher sein wird. Genau dieses Vertrauen wurde hier ausgenutzt.

Für die fachliche Einordnung lohnt sich deshalb eine klare Formulierung: Ja, viele suchen nach Axios Schwachstelle oder Axios Sicherheitslücke. Technisch präziser handelt es sich aber um einen kompromittierten npm-Release und damit um einen Supply-Chain-Angriff auf das offizielle Axios-Paket.

Hinzu kommt die enorme Verbreitung von Axios in Frontend-, Backend- und CI-Kontexten. Ein einzelner kompromittierter Release reicht deshalb aus, um eine sehr breite Mischung aus Entwicklerrechnern, SaaS-Builds, Docker-Images und Deployment-Pipelines zu berühren.

Zur Attribution gilt: Google Threat Intelligence ordnet die Kampagne dem Akteur UNC1069 zu, Reuters berichtet entsprechend über eine Nordkorea-Verbindung. Das sollte man aber sauber als Assessment und nicht als gerichtsfest bewiesene Tatsache formulieren.

Für Engineering-Teams steckt darin noch eine zweite, sehr menschliche Botschaft: Selbst wenn ein Maintainer 2FA aktiviert hat und grundsätzlich sicherheitsbewusst arbeitet, kann ein Konto oder ein Publish-Pfad trotzdem kompromittiert werden. Organisationen sollten deshalb nicht allein auf individuelles „richtiges Verhalten“ setzen, sondern auf zusätzliche Sicherheitsnetze wie Trusted Publishing, kurze Token-Laufzeiten, restriktive Paket-Policies, Lockfile-Disziplin und Monitoring ungewöhnlicher Release-Wege.

Was wir aus dem Axios npm Hack für künftige Releases lernen

Der Fall ist nicht nur ein Incident-Response-Thema. Er liefert auch eine konkrete Aufgabenliste für DevSecOps, Release Engineering und Paket-Maintainer.

# Beispiel: vorsichtiger Dependency-Job
steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-node@v4
    with:
      node-version: "22"
  - run: npm ci --ignore-scripts
  - run: npm audit --omit=dev
  - run: npm ls axios plain-crypto-js

Wichtig ist die Einordnung: --ignore-scripts ist keine Universallösung für jedes Projekt. Für viele CI-Schritte, in denen keine Postinstall-Logik gebraucht wird, ist es aber ein sinnvoller Default. Genau an solchen Stellen lässt sich die Angriffsoberfläche gegen Supply-Chain-Malware spürbar verkleinern.

Häufige Fragen zu Axios Schwachstelle, Axios npm und dem npm-Hack