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

Stand: 03. April 2026 - zuletzt aktualisiert

Autor: Mika Schmidt (IT-Security Consultant) – Six Eight Consulting, Fokus: Analyse, IAM, Security Engineering.

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. [Vulnerability DB] [Technische Analyse]

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. [Incident Response]

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. [Technische Analyse]

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. [Research] [Threat Research]

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. [Vulnerability DB] [Threat Research]

Verwandter Kontext: Shai-Hulud 2.0 zeigt, wie aggressiv npm-Supply-Chain-Angriffe inzwischen geworden sind .

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. [Incident Response]

Schnellcheck für Linux/macOS-Hosts und CI-Runner:

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
    

Schnellcheck für Windows-Endpoints:

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
    

Wenn Sie schnell belastbare Klarheit brauchen: Ein IT-Security Check hilft dabei, Exposure, Logs und Hardening priorisiert zu prüfen .

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. [Incident Response] [Vulnerability DB] [Threat Intelligence]

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. [Incident Response] [Technische Analyse]

1. Host isolieren und Build-Pfad stoppen: Keine weiteren Deployments, keine neuen Builds aus dem verdächtigen Workspace, Self-Hosted-Runner sofort aus dem Verkehr ziehen.
2. Credentials rotieren: npm-Tokens, GitHub-Tokens, Cloud-Keys, SSH-Schlüssel, CI/CD-Secrets, API-Keys und alles, was auf dem betroffenen Host verfügbar war.
3. Persistenz und Egress prüfen: Suche nach Artefakten, geplanten Tasks, Registry-Run-Keys, DNS- und Proxy-Treffern zu sfrclak[.]com und der bekannten IP.
4. Neu aufsetzen statt flicken: Wenn die Payload ausgeführt wurde, ist ein sauberer Rebuild oder ein neues Runner-Image in der Regel schneller und sicherer als langes Herumdoktern.
5. Supply-Chain-Spur rückwärts verfolgen: Welche Commits, Builds, Artefakte oder Container wurden von diesem Host aus erzeugt? Für mögliche Folgeschäden ist diese Frage oft wichtiger als die reine Paketliste.

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. [Incident Response]

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. [Research]

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. [Threat Intelligence] [News]

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. [Technische Analyse] [Security News / Update] [Doku] [Doku]

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 ziemlich konkrete Aufgabenliste für DevSecOps, Release Engineering und Paket-Maintainer.

Beispiel für einen konservativeren CI-Installationspfad:

# 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

Welche Axios-Versionen sind betroffen?

Betroffen sind axios@1.14.1 und axios@0.30.4. Beide Releases luden plain-crypto-js@4.2.1 nach und waren Teil der beschriebenen Angriffskette. [Vulnerability DB]

Reicht es, Axios einfach zu aktualisieren?

Nein. Sobald die kompromittierte Version auf einem Host installiert und ausgeführt wurde, muss dieser Host als potenziell kompromittiert behandelt werden. Update, Cache löschen und weitermachen reicht dann nicht aus. [Incident Response]

Ist das eine Axios Schwachstelle oder ein Axios-Wurm?

Eher nicht. Die Begriffe Axios Schwachstelle und Axios-Wurm passen zum Search Intent, technisch genauer ist aber: Supply-Chain-Kompromittierung mit postinstall-Dropper und RAT. Die bisher veröffentlichten Analysen beschreiben keine selbstreplizierende Malware im engen Sinn. [Vulnerability DB]

Welche Systeme muss ich jetzt prüfen?

Entwickler-Laptops, Self-Hosted-Runner, CI-Server, Build-Container, Preview-Umgebungen und jeden Host, auf dem während des kompromittierten Fensters ein frischer Install oder Lockfile-Resolve lief. Nur Produktionsserver zu prüfen, wäre hier klar zu wenig. [Incident Response]