Blog

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

Ashley Innocent

Ashley Innocent

2 April 2026

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

Apidog für Unternehmen

On-Premises-Bereitstellung

SSO & RBAC

SOC 2 konform

Apidog Enterprise entdecken

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.

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. Wenn ein so grundlegendes Paket kompromittiert wird, ist das Ausmaß der Auswirkungen enorm – Entwickler, die in einem engen Zeitfenster am 30.–31. März `npm install` ausgeführt haben, haben unwissentlich Malware auf ihre Maschinen heruntergeladen.

Dies ist kein hypothetisches Lieferkettenrisiko. Es ist geschehen, wurde bestätigt, und die Nutzlast war ernst: ein mehrstufiger Remote Access Trojaner, der beliebige Befehle ausführen, Systemdaten exfiltrieren und auf infizierten Maschinen persistent bleiben kann.

Wenn Ihr Team axios verwendet und Sie Apidog zum Entwerfen und Testen Ihrer HTTP-Client-Integrationen nutzen, lesen Sie dies vor Ihrem nächsten Deployment.

button

Chronologie des Angriffs

30. März 2026 — 23:59:12 UTC: Ein bösartiges Paket namens plain-crypto-js@4.2.1 wird von einem Konto mit nrwise@proton.me auf npm veröffentlicht. Eine frühere saubere Version (4.2.0) wurde 18 Stunden zuvor als überzeugendes Typosquatting der legitimen crypto-js-Bibliothek veröffentlicht.

31. März 2026 — 00:05:41 UTC: Die automatisierte Malware-Erkennung von Socket kennzeichnet plain-crypto-js@4.2.1 als bösartig – sechs Minuten nach der Veröffentlichung.

31. März 2026 — kurz nach Mitternacht: axios@1.14.1 wird auf npm veröffentlicht und zieht plain-crypto-js@4.2.1 als Abhängigkeit ein. Die Veröffentlichung erscheint nicht in den offiziellen Tags des axios GitHub-Repositorys. Der aktuellste legitime Tag bleibt v1.14.0.

31. März 2026 — Vormittag: Das GitHub-Issue #10604 wird öffentlich eröffnet und meldet sowohl axios@1.14.1 als auch axios@0.30.4 als kompromittiert. Die axios-Betreuer bestätigen, dass sie den Zugriff des Angreifers zunächst nicht widerrufen können – das kompromittierte Konto hat höhere npm-Berechtigungen als die legitimen Betreuer.

31. März 2026: Sowohl axios@1.14.1 als auch axios@0.30.4 werden von npm zurückgezogen. Die axios-Betreuer beginnen mit dem Widerruf von Tokens, der Verschärfung der Veröffentlichungskontrollen und der Untersuchung, wie ein langlebiges npm-Token ausgenutzt wurde, um unbefugten Veröffentlichungszugriff zu erhalten.

Wie der Angriff funktionierte

Der Angriff nutzte eine Lücke im Veröffentlichungs-Workflow von axios aus: ein langlebiges npm-Token, das zusammen mit vertrauenswürdiger Veröffentlichung verwendet worden war. Der Angreifer – wahrscheinlich nach der Kompromittierung der Zugangsdaten eines Betreuers – verwendete dieses Token, um eine neue Version außerhalb des normalen Release-Prozesses zu veröffentlichen.

Die neue Version führte plain-crypto-js@4.2.1 als Abhängigkeit ein. Der Paketname wurde so konzipiert, dass er wie ein legitimes Kryptographie-Dienstprogramm aussieht; die frühere saubere Version 4.2.0 etablierte eine kurze Historie, um den Verdacht zu mindern.

Innerhalb von plain-crypto-js@4.2.1 fand die Analyse von Socket eine mehrstufige Nutzlast:

  1. Stufe 1 — Ausführung: Das Paket führt zum Installationszeitpunkt Code aus (über npm-Lifecycle-Skripte), um eine sekundäre Nutzlast abzulegen.
  2. Stufe 2 — RAT-Bereitstellung: Die Nutzlast installiert einen Remote Access Trojaner, der eine persistente Hintertür öffnet.
  3. Stufe 3 — Exfiltration: Der RAT ist in der Lage, beliebige Shell-Befehle von einem C2-Server auszuführen, Umgebungsvariablen und Geheimnisse vom Dateisystem zu lesen und Systemdaten über das Netzwerk zu versenden.

Der RAT bleibt über Neustarts hinweg bestehen, was bedeutet, dass Maschinen, die die kompromittierte Version installiert haben, weiterhin gefährdet sind, selbst nachdem das npm-Paket entfernt wurde, es sei denn, der RAT wird explizit aufgespürt und entfernt.

Bin ich betroffen?

Sie sind potenziell betroffen, wenn:

Sofort überprüfen:

# Check installed version
npm list axios

# Check lock file
grep '"axios"' package-lock.json | head -5

# Check for plain-crypto-js presence
npm list plain-crypto-js
ls node_modules/plain-crypto-js 2>/dev/null && echo "INFECTED" || echo "Not found"

Wenn plain-crypto-js in Ihren node_modules vorhanden ist, haben Sie die bösartige Version ausgeführt.

Was jetzt zu tun ist

1. axios sofort aktualisieren

npm install axios@1.14.0
# or pin to latest safe
npm install axios@latest

Verifizieren:

npm list axios
# Should show 1.14.0 or higher (once a clean 1.14.x is published)

2. Wenn Sie die kompromittierte Version installiert haben

Behandeln Sie dies nicht als ein routinemäßiges Abhängigkeits-Update. Behandeln Sie die Maschine als kompromittiert:

3. Überprüfen Sie Ihre CI/CD-Pipelines

Wenn Ihre Build-Pipeline im betroffenen Zeitraum `npm install` ausgeführt hat, könnte Ihre CI-Umgebung kompromittiert worden sein. Überprüfen Sie:

# Check build logs for the affected timeframe
# Look for axios@1.14.1 in any install output

# Verify current CI node_modules are clean
npm list axios plain-crypto-js

Ändern Sie alle Geheimnisse (Secrets), auf die Ihre CI-Pipeline Zugriff hat: Bereitstellungsschlüssel, Cloud-Provider-Zugangsdaten, Registry-Tokens.

4. Überprüfen Sie Ihre Lock-Datei

Lock-Dateien (package-lock.json, yarn.lock) sollten exakte Versionen festlegen. Wenn Ihre Lock-Datei 1.14.1 enthält, generieren Sie sie neu:

# Remove and regenerate
rm package-lock.json
npm install

Überprüfen Sie, ob die neue Lock-Datei axios auf eine sichere Version auflöst, bevor Sie sie committen.

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

Wenn Sie axios als HTTP-Client für API-Aufrufe verwenden, kann Apidog Ihnen helfen zu überprüfen, ob Ihre Integration nach dem Abhängigkeits-Update noch die richtigen Anfragen sendet.

Nach dem Update auf axios@1.14.0 importieren Sie Ihre bestehenden API-Endpunkte in Apidog und führen Sie einen schnellen Regressionstest durch, um zu bestätigen, dass sich das Verhalten nicht geändert hat. Dies ist besonders nützlich, wenn Sie befürchten, dass die bösartige Version Anforderungs- oder Antwort-Payloads manipuliert haben könnte – die Antwort-Assertions von Apidog ermöglichen es Ihnen, genaue Feldwerte, Header und Statuscodes zu validieren:

// 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;
});

Das Ausführen Ihrer vollständigen Testsuite gegen die aktualisierte axios-Version in Apidog liefert Ihnen eine dokumentierte saubere Ausgangsbasis, bevor Sie in die Produktion gehen.

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

Warum Lieferkettenangriffe auf npm schwer zu stoppen sind

Der axios-Angriff ist keine Anomalie. Er folgt einem Muster:

Der rote Faden: Vertrauen in das veröffentlichende Konto, nicht in den Code. Das npm-Modell gewährt Betreuern Veröffentlichungszugriff, und wenn die Zugangsdaten eines Betreuers kompromittiert werden, erbt der Angreifer dieses Vertrauen.

Maßnahmen, die tatsächlich helfen:

Maßnahme Was es bewirkt
Lock-Dateien (package-lock.json) Fixiert exakte Versionen, verhindert stille Upgrades
npm audit in CI Kennzeichnet bekannte Schwachstellen vor der Bereitstellung
Socket.dev / Snyk Verhaltensanalyse — kennzeichnet verdächtige Pakete, noch bevor CVEs existieren
Zwei-Faktor-Authentifizierung auf npm Erschwert die Kompromittierung von Zugangsdaten
npm publish mit kurzlebigen Tokens Begrenzt das Expositionsfenster, falls ein Token undicht wird
Lock-Dateien in PRs lesen Unerwartete Abhängigkeitsänderungen im Code-Review erkennen

Das axios-Team hat seitdem anerkannt, dass langlebige npm-Tokens Teil des Problems waren, und geht zu strengeren Veröffentlichungskontrollen über. Die Lösung muss jedoch vom Ökosystem kommen, nicht nur von einzelnen Paketen.

Indikatoren einer Kompromittierung (IOCs)

Laut Sockets Analyse:

Wenn Sie eine Infektion vermuten, reichen Sie einen Bericht bei npm security unter security@npmjs.com ein und sichern Sie die Protokolle.

Fazit

Die Kompromittierung von axios 1.14.1 ist eine Erinnerung daran, dass Abhängigkeitssicherheit keine einmalige Prüfung ist – es ist ein kontinuierlicher Prozess. Sperren Sie Ihre Versionen, führen Sie Verhaltensanalysetools wie Socket in Ihrer CI aus, ändern Sie Zugangsdaten, wenn etwas ungewöhnlich aussieht, und überprüfen Sie Ihre Lock-Dateien im Code-Review.

Wenn Sie nach dem Aktualisieren von axios das Vertrauen in Ihre API-Integration wiederherstellen müssen, bietet Ihnen Apidog die Testszenarien, Assertions und Mocking-Tools, um das Verhalten Ihres HTTP-Clients zu überprüfen, bevor Sie ihn veröffentlichen.

button

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 (oder jede Version der Reihen 1.13.x, 1.12.x).

Was bewirkt die bösartige axios-Nutzlast?Sie zieht plain-crypto-js@4.2.1 ein, welches eine mehrstufige Nutzlast einschließlich eines Remote Access Trojaners (RAT) bereitstellt. Der RAT kann beliebige Befehle von einem entfernten C2-Server ausführen, Umgebungsvariablen und Geheimnisse exfiltrieren und über Neustarts hinweg bestehen bleiben.

Woher weiß ich, ob ich die kompromittierte Version installiert habe?Führen Sie `npm list axios` aus – wenn es 1.14.1 oder 0.30.4 anzeigt, sind Sie betroffen. Überprüfen Sie auch `npm list plain-crypto-js` – wenn dieses Paket vorhanden ist, wurde der bösartige Code auf Ihrer Maschine ausgeführt.

Reicht es aus, axios einfach zu aktualisieren?Nein. Das Update entfernt die bösartige Abhängigkeit für die Zukunft, aber der RAT könnte bereits auf der Maschine installiert sein und bestehen bleiben. Wenn Sie die kompromittierte Version installiert haben, ändern Sie alle Geheimnisse (Secrets) und überprüfen Sie die Maschine auf Persistenzmechanismen.

Wie konnte der Angreifer auf npm veröffentlichen, ohne ein Betreuer zu sein?Der Angreifer hat wahrscheinlich die Zugangsdaten eines Betreuers kompromittiert und ein langlebiges npm-Token ausgenutzt, das über Veröffentlichungszugriff verfügte. Das axios-Team untersucht den Vorfall und verschärft die Veröffentlichungskontrollen.

Was ist der Unterschied zwischen diesem und einer regulären Schwachstelle?Eine Schwachstelle ist ein Fehler in legitimen Code. Ein Lieferkettenangriff führt bösartigen Code über einen vertrauenswürdigen Veröffentlichungskanal ein. Der kompromittierte Code befand sich nie im axios GitHub-Repository – er wurde direkt in die npm-Veröffentlichung injiziert.

Wie kann ich meine Projekte vor zukünftigen Lieferkettenangriffen schützen?Verwenden Sie Lock-Dateien, führen Sie `npm audit` in CI aus, fügen Sie ein Tool wie Socket.dev zur Verhaltensanalyse hinzu, aktivieren Sie 2FA für npm-Konten, verwenden Sie kurzlebige Veröffentlichungs-Tokens und überprüfen Sie Ihre Lock-Datei-Diffe im Code-Review.

Praktizieren Sie API Design-First in Apidog

Entdecken Sie eine einfachere Möglichkeit, APIs zu erstellen und zu nutzen

Kostenlos registrierenDownload