DEV Community

Cover image for Axios NPM Supply Chain Angriff: API Projekte schützen
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

Axios NPM Supply Chain Angriff: API Projekte schützen

#api #javascript #npm #security

Kurz gesagt

Am 31. März 2026 wurde das npm-Konto des Hauptmaintainers von Axios, dem meistgenutzten JavaScript HTTP-Client (83 Mio. wöchentliche Downloads), kompromittiert. Angreifer veröffentlichten bösartige Versionen (1.14.1 und 0.30.4) mit einem plattformübergreifenden Remote Access Trojaner (RAT), der Zugangsdaten, SSH-Schlüssel und Cloud-Tokens von Entwicklerrechnern stiehlt. Sofortiges Downgrade auf Axios 1.14.0, Änderung aller Geheimnisse und Prüfung auf Kompromittierungsindikatoren sind Pflicht.

Teste Apidog noch heute

Einleitung

Axios verarbeitet mehr HTTP-Anfragen als jede andere JavaScript-Bibliothek. Wenn du in den letzten Jahren einen API-Client gebaut, Endpunkte getestet oder ein Frontend ans Backend angebunden hast, hast du wahrscheinlich Axios verwendet.

Am 31. März 2026 um 00:21 Uhr UTC veröffentlichte ein Angreifer Axios 1.14.1 über ein kompromittiertes Maintainer-Konto. Das Paket war nahezu identisch mit der legitimen Version – mit einer entscheidenden Änderung in der package.json: Eine neue Abhängigkeit plain-crypto-js wurde injiziert, die einen Remote Access Trojaner beim Ausführen von npm install installierte.

Die betroffenen Versionen blieben etwa 2–3 Stunden online, bevor npm sie entfernte – bei 83 Millionen wöchentlichen Downloads.

💡 Wenn du APIs entwickelst oder testest, zielte dieser Angriff direkt auf deine Toolchain. Der integrierte HTTP-Client von Apidog macht externe HTTP-Bibliotheken im API-Test-Prozess überflüssig – und eliminiert diese Angriffsfläche.

In diesem Beitrag findest du: Wie der Angriff ablief, wie du prüfst, ob dein System betroffen ist, und welche konkreten Maßnahmen API-Teams im Abhängigkeitsmanagement umsetzen sollten.

Wie sich der Axios-Supply-Chain-Angriff entfaltete

Der Zeitplan

Der Angriff erfolgte in einem präzisen 18-Stunden-Fenster:

  • 30. März, 05:57 UTC: Unverdächtiges Köderpaket plain-crypto-js@4.2.0 auf npm veröffentlicht.
  • 30. März, 23:59 UTC: Bösartige Version plain-crypto-js@4.2.1 mit postinstall-Hook und Dropper bereitgestellt.
  • 31. März, 00:21 UTC: axios@1.14.1 über kompromittiertes Konto veröffentlicht.
  • 31. März, 01:00 UTC: axios@0.30.4 folgt kurz darauf für Projekte, die noch 0.x nutzen.
  • 31. März, ~03:15 UTC: npm entfernt beide Axios-Versionen nach Community-Hinweisen.
  • 31. März, 04:26 UTC: npm veröffentlicht einen Security-Stub für plain-crypto-js, um erneute Veröffentlichung zu verhindern.

Wie das Konto kompromittiert wurde

Der Angreifer übernahm das jasonsaayman-npm-Konto, wechselte die E-Mail zu ifstap@proton.me. Hinweise für forensische Prüfung:

  • Legitime Releases nutzen GitHub Actions mit OIDC Trusted Publisher. Die bösartigen Versionen hatten keine OIDC-Bindung.
  • Kein gitHead-Feld in den kompromittierten Releases – keine zugehörigen GitHub-Commits.
  • Veröffentlichung erfolgte manuell mit gestohlenen, langlebigen npm-Tokens statt über CI/CD.

Tipp: Wenn deine Organisation npm-Pakete veröffentlicht, prüfe Releases automatisiert auf OIDC-Bindung und CI/CD-Quelle.

Die Abhängigkeitsinjektion

Nur eine Zeile in der package.json von Axios wurde geändert: Hinzufügen von plain-crypto-js@^4.2.1 als Runtime-Abhängigkeit. Das Paket wird nicht im Code importiert, sondern löst allein durch den postinstall-Hook die Schadfunktion beim npm install aus.

Binärvergleich: Nur package.json unterscheidet sich zwischen 1.14.0 (clean) und 1.14.1 (kompromittiert).

Was die bösartige Nutzlast tut

Der Dropper-Mechanismus

Der postinstall-Hook in plain-crypto-js führt eine 4,2 KB große, doppelt obfuskierte Datei setup.js aus:

  1. XOR-Verschlüsselung mit Schlüssel aus "OrDeR_7077"
  2. Base64-Kodierung mit Zeichenumkehr

Nach Dekodierung erkennt der Dropper das Betriebssystem und lädt plattformspezifische Nutzlasten.

Plattformwege

macOS:

Writes AppleScript to /tmp/6202033
Executes via osascript
Downloads payload to /Library/Caches/com.apple.act.mond
Enter fullscreen mode Exit fullscreen mode

Windows:

Copies PowerShell to %PROGRAMDATA%\wt.exe (Persistenz)
Executes VBScript dropper via cscript
Enter fullscreen mode Exit fullscreen mode

Linux:

Downloads Python RAT to /tmp/ld.py
Executes via nohup python3
Enter fullscreen mode Exit fullscreen mode

Alle Varianten kommunizieren mit einem Command-and-Control-Server (C2):

  • macOS: packages.npm.org/product0
  • Windows: packages.npm.org/product1
  • Linux: packages.npm.org/product2

RAT-Fähigkeiten

  • Shell-Befehle ausführen
  • Dateisystem scannen und exfiltrieren
  • Prozesse auflisten und injizieren
  • In-Memory-Injektion (fileless)
  • 60s Beacon-Intervalle zur C2

Risiko: Vollständige Fernsteuerung über den Entwicklerrechner, Zugriff auf .env, SSH-Keys, Cloud-Tokens etc.

Anti-Forensik

Nach Ausführung:

  1. Löscht setup.js
  2. Entfernt bösartige package.json
  3. Benennt package.md (saubere 4.2.0) in package.json um

So täuscht ein späteres npm list die saubere Version vor.

Wer steckt hinter dem Angriff?

Laut Google Threat Intelligence Group ist UNC1069 (vermutlich nordkoreanisch) verantwortlich. Die macOS-Malware ähnelt stark WAVESHAPER, einer bekannten Backdoor. Ziel: Entwickler-Workstations, Credential- und Token-Diebstahl in großem Maßstab.

So prüfst du, ob du betroffen bist

Schritt 1: Axios-Version prüfen

In jedem Projekt mit Axios:

npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"
Enter fullscreen mode Exit fullscreen mode

Gibt es Treffer, ist eine kompromittierte Version installiert.

Schritt 2: Bösartige Abhängigkeit prüfen 

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

Existiert das Verzeichnis, wurde die Nutzlast ausgeführt.

Schritt 3: System nach RAT-Artefakten durchsuchen

macOS:

ls -la /Library/Caches/com.apple.act.mond 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Linux:

ls -la /tmp/ld.py 2>/dev/null
Enter fullscreen mode Exit fullscreen mode

Windows (PowerShell):

Test-Path "$env:PROGRAMDATA\wt.exe"
Enter fullscreen mode Exit fullscreen mode

Schritt 4: Netzwerk-Indikatoren prüfen

Blockiere und scanne auf folgende Ziele:

  • C2-Domain: sfrclak.com
  • C2-IP: 142.11.206.73
  • C2-URL: http://sfrclak.com:8000/6202033

Schritt 5: CI/CD-Build-Logs prüfen

Alle CI/CD-Ausführungen zwischen 31. März 00:21–03:15 UTC prüfen. Jedes npm install/ci, das Axios installierte, könnte infiziert sein.

Sofortige Maßnahmen

1. Axios sofort downgraden 

npm install axios@1.14.0
Enter fullscreen mode Exit fullscreen mode

Für 0.x-Branch:

npm install axios@0.30.3
Enter fullscreen mode Exit fullscreen mode

2. Versions-Overrides in package.json setzen

Verhindert transitive Auflösung bösartiger Versionen:

npm:

{
  "overrides": {
    "axios": "1.14.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

Yarn:

{
  "resolutions": {
    "axios": "1.14.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

3. Bösartiges Paket entfernen 

rm -rf node_modules/plain-crypto-js
Enter fullscreen mode Exit fullscreen mode

4. Alle Zugangsdaten ändern

Gehe davon aus, dass folgende Daten kompromittiert sind:

  • npm-Tokens
  • AWS/GCP/Azure-Credentials
  • SSH-Keys
  • GitHub-Tokens
  • API-Keys aus .env
  • DB-Logins
  • Secrets in Env-Variablen

Alles ändern! Man weiß nicht, was exfiltriert wurde.

5. C2 auf Netzwerkebene blockieren 

echo "0.0.0.0 sfrclak.com" | sudo tee -a /etc/hosts
Enter fullscreen mode Exit fullscreen mode

6. Bei Funden System neu aufsetzen

Wurden Artefakte gefunden: Rechner aus einem vertrauenswürdigen Backup neu aufsetzen – RAT kann alles verändert haben.

Langfristige Schutzmaßnahmen für API-Teams

Lockfiles und exakte Versionen nutzen

Der Angriff nutzte den ^-Semver-Bereich aus. Setze exakte Versionen und committe Lockfiles. Nutze in CI/CD immer npm ci:

{
  "dependencies": {
    "axios": "1.14.0"
  }
}
Enter fullscreen mode Exit fullscreen mode

Postinstall-Skripte in CI/CD deaktivieren

Verhindere das Ausführen von postinstall-Hooks:

npm ci --ignore-scripts
Enter fullscreen mode Exit fullscreen mode

Für Pakete, die native Kompilierung brauchen, selektiv via .npmrc erlauben:

ignore-scripts=true
Enter fullscreen mode Exit fullscreen mode

Abhängigkeiten regelmäßig prüfen 

npm audit
npx socket-security/cli audit
Enter fullscreen mode Exit fullscreen mode

Automatisiere das als CI/CD-Gate.

Reduziere HTTP-Client-Abhängigkeiten

Frage dich: Brauchst du wirklich eine externe HTTP-Bibliothek im Test-Workflow?

Apidog bietet z.B. einen integrierten HTTP-Client für API-Tests, Debugging und Dokumentation – keine npm-Abhängigkeit, kein Supply-Chain-Risiko.

Konkret:

  • API-Tests: Nutze den visuellen Test-Builder statt Axios-Skripte
  • API-Debugging: Nutze den integrierten Request-Inspector
  • Mock-Server: Nutze Smart Mock statt eigener Mocks via Express + Axios
  • CI/CD: Nutze Apidog CLI für automatisierte API-Tests ohne npm-HTTP-Bibliotheken

Teste Apidog kostenlos, um deinen API-Workflow ohne HTTP-Client-Abhängigkeit abzusichern.

Paket-Provenienz überprüfen

npm unterstützt Paket-Provenienz via Sigstore:

npm audit signatures
Enter fullscreen mode Exit fullscreen mode

Fehlende Provenienz (z.B. OIDC-Bindung) ist ein Alarmzeichen.

Was bedeutet das für das JavaScript-Ökosystem?

Vertrauensmodell ist defekt

Eine kompromittierte Maintainer-Anmeldung genügt, um 83 Millionen Projekte pro Woche zu treffen. 2FA hilft, aber gestohlene Tokens bleiben ein Risiko.

Diskutierte Maßnahmen:

  • Pflicht-OIDC-Releases ab bestimmtem Download-Level
  • Zwei-Personen-Freigabe für kritische Pakete
  • Runtime-Berechtigungen für Skripte (analog Deno)

Supply-Chain-Angriffe nehmen zu

Nur Tage nach RubyGems- und PyPI-Vorfällen: Paketregister aller Ökosysteme stehen unter Dauerbeschuss. Jeder Abhängigkeitsbaum ist eine Angriffsfläche.

Zitat aus der Reddit-Diskussion:

„NPM ist heute die größte Schwachstelle des Internets und wird immer noch eine riesige Katastrophe verursachen.“

Der Axios-Angriff zeigt, dass der Explosionsradius real ist.

Vergleich: HTTP-Client-Abhängigkeitsansätze

Ansatz Supply-Chain-Risiko Wartungsaufwand Testfähigkeit
Axios + benutzerdefinierte Skripte Hoch (Drittanbieter-Abhängigkeit) Hoch (Versionsverwaltung) Manuelle Einrichtung erforderlich
Node.js native Fetch Niedrig (im Laufzeitumgebung integriert) Niedrig Eingeschränkte Testfunktionen
Apidog integrierter Client Keine (keine npm-Abhängigkeit) Keine (Plattform-verwaltet) Volle Test-, Mock- und Dokumentationsfunktionen
curl/httpie Skripte Niedrig (System-Tool) Mittel Eingeschränkte Automatisierung

FAQ

Ist Axios jetzt sicher zu verwenden?

Ja. Die Versionen 1.14.0 und 0.30.3 sind sauber. Die kompromittierten Versionen (1.14.1, 0.30.4) wurden nach ca. drei Stunden entfernt. Prüfe mit npm list axios und kontrolliere dein Lockfile.

Wie erkenne ich, ob der RAT auf meinem Rechner lief?

Suche nach plattformspezifischen Artefakten:

  • /Library/Caches/com.apple.act.mond (macOS)
  • /tmp/ld.py (Linux)
  • %PROGRAMDATA%\wt.exe (Windows)
  • Prüfe, ob node_modules/plain-crypto-js existiert.

Fehlende Artefakte sind kein Garant für Sicherheit, wenn eine kompromittierte Version installiert war.

Sollte ich Axios komplett meiden?

Nicht zwingend. Axios bleibt eine gepflegte Bibliothek mit guter Historie. Der Vorfall sollte aber dazu führen, kritisch zu prüfen, ob du überhaupt einen Drittanbieter-HTTP-Client brauchst (Node.js 18+ hat natives fetch). Für API-Tests bieten Plattformen wie Apidog integrierte Clients ohne npm-Abhängigkeit.

Wie verhindere ich Supply-Chain-Angriffe in meinen Projekten?

  • Exakte Abhängigkeitsversionen und Lockfiles committen
  • npm ci --ignore-scripts in CI/CD nutzen
  • Abhängigkeiten regelmäßig prüfen (npm audit signatures)
  • Abhängigkeitsbaum minimieren
  • API-Test-Workflows auf integrierte Tools ohne npm-HTTP-Client verlagern

Hängt der Angriff mit dem Claude-Code-Leak zusammen?

Beide Ereignisse fanden am 31. März 2026 statt, sind aber unabhängig. Der Axios-Angriff war gezielte Supply-Chain-Kompromittierung, der Claude-Leak entstand durch einen Fehler im Bun-Build-Tool.

Wer steckte hinter dem Axios-Angriff?

Google ordnet den Angriff UNC1069 zu (vermutlich Nordkorea). Die Malware ähnelt WAVESHAPER-Backdoors. Ziel: Entwickler-Zugangsdaten und Krypto-Infrastruktur.

Wie viele Entwickler waren betroffen?

Die bösartigen Versionen waren ca. 2–3 Stunden aktiv. Bei 83 Mio. wöchentlichen Downloads ist das potentielle Risiko groß. npm hat keine offiziellen Zahlen veröffentlicht.

Kann Apidog helfen, Supply-Chain-Angriffe zu verhindern?

Apidog reduziert das Risiko, indem es einen integrierten HTTP-Client für API-Tests, Debugging und Doku bereitstellt – keine Installation von Axios oder anderen HTTP-Bibliotheken notwendig. Das minimiert die npm-Angriffsfläche im API-Workflow.

Wichtige Erkenntnisse

  • Der Axios-Supply-Chain-Angriff kompromittierte 83+ Mio. wöchentliche Downloads durch ein gestohlenes Maintainer-Konto
  • Der RAT zielte auf alle Plattformen und stahl Zugangsdaten, SSH-Keys, Cloud-Tokens
  • Prüfe deine Systeme mit den obigen Schritten
  • Setze exakte Abhängigkeitsversionen, deaktiviere Postinstall-Skripte in CI/CD
  • Reduziere HTTP-Client-Abhängigkeiten durch integrierte Tools wie Apidog
  • Die Sicherheit von Paketregistern ist ein systemisches, sprachenübergreifendes Problem

Der Axios-Angriff ist ein Weckruf: Jede Abhängigkeit in deinen node_modules ist eine Vertrauensentscheidung. Triff diese bewusst – nicht aus Bequemlichkeit.

Top comments (0)