DEV Community

Cover image for axios@1.14.1 Supply Chain Attacke: Was jetzt zu tun ist
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

axios@1.14.1 Supply Chain Attacke: Was jetzt zu tun ist

#javascript #news #npm #security

Kurz gesagt

Am 30.–31. März 2026 wurden die axios-Versionen 1.14.1 und 0.30.4 auf npm mit einer bösartigen Abhängigkeit kompromittiert, die einen Remote Access Trojaner (RAT) auf infizierten Maschinen platziert. Beide Versionen wurden von der Veröffentlichung zurückgezogen. Die sichere Version ist 1.14.0. Wenn Sie axios@1.14.1 oder 0.30.4 installiert haben, behandeln Sie die Maschine als kompromittiert und ändern Sie sofort alle Zugangsdaten.

Apidog jetzt ausprobieren

Was axios ist und warum dies wichtig ist

axios hat wöchentlich 100 Millionen Downloads auf npm. Es ist der HTTP-Client in unzähligen Frontend-Frameworks, Backend-Node.js-Diensten und Unternehmensanwendungen. Wird ein so grundlegendes Paket kompromittiert, sind die Auswirkungen gravierend – Entwickler, die im Zeitfenster 30.–31. März npm install ausgeführt haben, haben unwissentlich Malware installiert.

Das ist kein theoretisches Risiko. Es ist passiert, bestätigt und die Nutzlast war ernst: Ein mehrstufiger Remote Access Trojaner, der beliebige Befehle ausführen, Systemdaten exfiltrieren und persistieren kann.

Wenn Ihr Team axios nutzt und Sie Apidog zum Testen Ihrer HTTP-Integrationen einsetzen, lesen Sie weiter, bevor Sie deployen.

Chronologie des Angriffs

30. März 2026 — 23:59:12 UTC:

Ein bösartiges Paket namens plain-crypto-js@4.2.1 wird von nrwise@proton.me auf npm veröffentlicht. Eine saubere Version (4.2.0) wurde 18 Stunden zuvor als Typosquatting der legitimen crypto-js-Bibliothek veröffentlicht.

31. März 2026 — 00:05:41 UTC:

Die automatisierte Malware-Erkennung von Socket meldet plain-crypto-js@4.2.1 als bösartig – sechs Minuten nach Veröffentlichung.

31. März 2026 — kurz nach Mitternacht:

axios@1.14.1 erscheint auf npm und zieht plain-crypto-js@4.2.1 als Abhängigkeit ein. Dieser Release erscheint nicht in den offiziellen Tags des axios GitHub-Repositorys. Der neueste legitime Tag bleibt v1.14.0.

31. März 2026 — Vormittag:

Das GitHub-Issue #10604 meldet axios@1.14.1 und axios@0.30.4 als kompromittiert. Die axios-Betreuer bestätigen, dass sie den Angreiferzugriff zunächst nicht entfernen können – das kompromittierte Konto hatte höhere npm-Berechtigungen.

31. März 2026:

Beide Versionen werden von npm zurückgezogen. Die axios-Betreuer widerrufen Tokens, verschärfen Release-Kontrollen und untersuchen, wie ein langlebiges npm-Token missbraucht wurde.

Wie der Angriff funktionierte

Der Angriff nutzte ein langlebiges npm-Token im Release-Workflow aus. Nach der Kompromittierung eines Betreuer-Zugangs veröffentlichte der Angreifer eine neue Version außerhalb des üblichen Release-Prozesses.

Die neue Version zog plain-crypto-js@4.2.1 als Abhängigkeit hinzu. Der Paketname sollte wie ein legitimes Kryptographie-Utility wirken; die saubere Version 4.2.0 schuf Historie, um Verdacht zu mindern.

Socket identifizierte folgende Angriffsstufen in plain-crypto-js@4.2.1:

  1. Stufe 1 — Ausführung: Beim Installieren wird Code via npm-Lifecycle-Skripte ausgeführt, der eine zweite Nutzlast ablegt.
  2. Stufe 2 — RAT-Bereitstellung: Installation eines Remote Access Trojaners, der eine persistente Hintertür öffnet.
  3. Stufe 3 — Exfiltration: Der RAT kann Shell-Befehle ausführen, Umgebungsvariablen und Secrets lesen und Systemdaten exfiltrieren.

Der RAT bleibt über Neustarts persistiert. Maschinen, die die kompromittierte Version installiert haben, sind weiter gefährdet, selbst nach Entfernen des npm-Pakets, solange der RAT nicht gezielt entfernt wird.

Bin ich betroffen?

Sie sind betroffen, wenn:

  • Sie zwischen 30. März, 23:59 UTC und 31. März 2026, mittags UTC ein npm install axios oder npm install (mit axios in package.json) ausgeführt haben.
  • Ihre Datei node_modules/axios/package.json die Version 1.14.1 oder 0.30.4 anzeigt.
  • Ihre package-lock.json oder yarn.lock axios auf 1.14.1 oder 0.30.4 auflöst.

Checkliste zum Überprüfen:

# Installierte Version prüfen
npm list axios

# Lock-Datei prüfen
grep '"axios"' package-lock.json | head -5

# Nach plain-crypto-js suchen
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFIZIERT" || echo "Nicht gefunden"
Enter fullscreen mode Exit fullscreen mode

Wenn plain-crypto-js in Ihren node_modules liegt, wurde die bösartige Version ausgeführt.

Was jetzt zu tun ist

1. axios sofort aktualisieren 

npm install axios@1.14.0
# oder auf die neueste sichere Version pinnen
npm install axios@latest
Enter fullscreen mode Exit fullscreen mode

Verifizierung:

npm list axios
# Sollte 1.14.0 oder höher anzeigen (sobald ein bereinigtes 1.14.x verfügbar ist)
Enter fullscreen mode Exit fullscreen mode

2. Wenn Sie die kompromittierte Version installiert haben

Behandeln Sie dies als vollständigen Sicherheitsvorfall:

  • Alle Zugangsdaten (Secrets) ändern: API-Schlüssel, Datenbank-Credentials, SSH-Keys, Cloud-Provider-Tokens, .env-Dateien.
  • Umgebungsvariablen prüfen: Der RAT exfiltriert gezielt Secrets aus Umgebungsvariablen und Filesystem.
  • Ausgehende Netzwerkverbindungen prüfen: Suchen Sie im fraglichen Zeitraum nach Verbindungen zu unbekannten IPs.
  • Persistenzmechanismen suchen: Cronjobs, Startskripte und systemd-Dienste auf neue Einträge im Kompromittierungszeitraum überprüfen.
  • Maschine neu aufsetzen: Bei CI-Runnern oder Produktionssystemen unbedingt ein Re-Imaging durchführen. Bei Entwickler-Laptops: Secrets kompromittiert betrachten und alles ändern, bevor die Maschine weiterverwendet wird.

3. CI/CD-Pipelines prüfen

Wenn Ihre Build-Pipeline im betroffenen Zeitraum npm install ausgeführt hat, ist Ihre CI-Umgebung potenziell betroffen.

# Build-Logs im betroffenen Zeitraum prüfen
# Nach axios@1.14.1 im Install-Output suchen

# Aktuelle CI node_modules prüfen
npm list axios plain-crypto-js
Enter fullscreen mode Exit fullscreen mode

Alle Secrets ändern, auf die die CI-Pipeline Zugriff hat: Deploy-Keys, Cloud-Zugangsdaten, Registry-Tokens.

4. Lock-Datei prüfen

Lock-Dateien (package-lock.json, yarn.lock) sollten keine kompromittierten Versionen enthalten. Falls doch, Datei löschen und neu generieren:

# Lock-Datei entfernen und neu erstellen
rm package-lock.json
npm install
Enter fullscreen mode Exit fullscreen mode

Vor dem Commit sicherstellen, dass die neue Lock-Datei axios auf eine sichere Version auflöst.

Apidog zur Überprüfung Ihrer axios API-Aufrufe verwenden

Setzen Sie axios als HTTP-Client ein, kann Apidog Sie bei der Prüfung unterstützen, ob Ihre Integration nach dem Update weiterhin korrekt funktioniert.

Vorgehen:

  • Nach Update auf axios@1.14.0 Ihre API-Endpunkte in Apidog importieren.
  • Regressionstests durchführen, um Änderungen im Verhalten auszuschließen.
  • Mit den Assertion-Features von Apidog prüfen, ob keine Payloads oder Header manipuliert wurden: 
// Apidog Post-Response Assertion
pm.test("Response is clean — no injected fields", () => {
    const body = pm.response.json();
    pm.expect(body).to.not.have.property('__injected');
    pm.expect(pm.response.headers.get('X-Injected-Header')).to.be.null;
});
Enter fullscreen mode Exit fullscreen mode

Führen Sie Ihre komplette Testsuite gegen die bereinigte axios-Version in Apidog aus und dokumentieren Sie das Ausgangsverhalten vor dem Produktions-Rollout.

Apidog kostenlos testen, um HTTP-Client-Regressionstests einzurichten.

Warum Lieferkettenangriffe auf npm schwer zu stoppen sind

Der axios-Angriff ist kein Einzelfall. Das Muster wiederholt sich:

  • event-stream (2018): Nutzlast zur Bitcoin-Wallet-Exfiltration. 8 Mio. Downloads/Woche.
  • ua-parser-js (2021): Kompromittierung zur Installation von Cryptominern und Passwortdieben.
  • node-ipc (2022): Maintainer fügt destruktiven Code gegen russische/weißrussische IPs ein.
  • xz utils (2024): Zwei Jahre Social Engineering für die Hintertür einer zentralen Linux-Bibliothek.
  • axios (2026): Kompromittierte Betreuer-Zugänge für RAT-Release über Abhängigkeit.

Zentral:

Das Vertrauen gilt dem veröffentlichenden Konto, nicht dem Code. Werden Maintainer-Zugangsdaten kompromittiert, erbt der Angreifer sofort das Release-Vertrauen.

Empfohlene Maßnahmen:

Maßnahme Wirkung
Lock-Dateien (package-lock.json) Fixiert exakte Versionen, verhindert stille Upgrades
npm audit in CI Meldet bekannte Schwachstellen vor Deployment
Socket.dev / Snyk Verhaltensanalyse – erkennt verdächtige Pakete früh
Zwei-Faktor-Authentifizierung auf npm Erschwert Kompromittierung von Maintainer-Accounts
npm publish mit kurzlebigen Tokens Begrenzt das Expositionsfenster bei Token-Leakage
Lock-Dateien in PRs prüfen Unerwartete Abhängigkeitsänderungen im Review erkennen

Das axios-Team verschärft die Release-Kontrollen und setzt auf kurzlebige Tokens. Die nachhaltige Lösung muss jedoch vom gesamten Ökosystem ausgehen.

Indikatoren einer Kompromittierung (IOCs)

Basierend auf der Analyse von Socket:

  • Bösartige Pakete: plain-crypto-js@4.2.1, axios@1.14.1, axios@0.30.4
  • E-Mail des Herausgebers: nrwise@proton.me
  • Verhalten: Netzwerkverbindungen bei npm-Installation, RAT-Persistenz, Exfiltration von Secrets
  • Sichere axios-Versionen: 1.14.0 und älter (außer 0.30.4), 1.13.x, 1.12.x

Bei Infektionsverdacht: Bericht an npm security (security@npmjs.com) senden und Logs sichern.

Fazit

Die axios-Komprimittierung zeigt: Abhängigkeits-Sicherheit ist ein fortlaufender Prozess. Versionen pinnen, Tools wie Socket in CI, Zugangsdaten bei Auffälligkeiten ändern, Lock-Dateien im Review prüfen.

Möchten Sie nach einem axios-Update Ihre API-Integration validieren, bietet Ihnen Apidog Assertions, Mocking und Regressionstests, um Ihren HTTP-Client abzusichern, bevor Sie releasen.

Häufig gestellte Fragen (FAQ)

Welche axios-Versionen sind kompromittiert?

axios@1.14.1 und axios@0.30.4. Beide wurden von npm zurückgezogen. Die sichere Version ist 1.14.0 (bzw. jede 1.13.x, 1.12.x).

Was bewirkt die bösartige axios-Nutzlast?

Sie zieht plain-crypto-js@4.2.1 ein, das einen mehrstufigen Remote Access Trojaner (RAT) bereitstellt. Dieser kann Befehle empfangen, Secrets exfiltrieren und persistieren.

Woher weiß ich, ob ich die kompromittierte Version installiert habe?

Führen Sie npm list axios aus – erscheint 1.14.1 oder 0.30.4, sind Sie betroffen. Prüfen Sie zusätzlich npm list plain-crypto-js – ist das Paket vorhanden, lief der bösartige Code.

Reicht ein Update auf eine saubere Version?

Nein. Das Update entfernt die Abhängigkeit für die Zukunft, aber der RAT könnte schon installiert und aktiv sein. Ändern Sie alle Secrets und prüfen Sie die Maschine auf Persistenzmechanismen.

Wie konnte der Angreifer auf npm veröffentlichen?

Wahrscheinlich durch kompromittierte Maintainer-Zugangsdaten und ein langlebiges npm-Token mit Release-Rechten. Das axios-Team zieht Konsequenzen und verschärft Release-Kontrollen.

Was ist der Unterschied zu einer regulären Schwachstelle?

Eine Schwachstelle ist ein Bug im legitimen Code. Ein Lieferkettenangriff bringt bösartigen Code über einen vertrauenswürdigen Release-Kanal ein – der Code war nie im axios-GitHub, sondern wurde direkt ins npm-Paket injiziert.

Wie kann ich meine Projekte vor Lieferkettenangriffen schützen?

Lock-Dateien nutzen, npm audit in CI, Socket.dev oder ähnliche Tools für Verhaltensanalyse, 2FA für npm-Konten, kurzlebige Publish-Tokens und Lockfile-Diffs im Code-Review überprüfen.

Top comments (0)