Wenn Sie Zeit in der JavaScript-Welt verbracht haben, haben Sie Axios berührt. Es ist die Standardeinstellung für HTTP-Anfragen in Node.js. Es ist so üblich, dass wir es normalerweise als Teil der Sprache selbst behandeln. Aber vor ein paar Wochen geriet die Branche in einen kollektiven Zusammenbruch. Schlagzeilen machten die Runde über eine kritische 10/10-Sicherheitslücke in Axios — CVE-2026-40175 —, die es Angreifern angeblich ermöglichte, die AWS-Sicherheit zu umgehen und Cloud-Anmeldeinformationen zu stehlen.

Bei Sweent ist unser erster Schritt, wenn eine „10/10" fällt, ein portfolioweites Audit einzuleiten. Ganz gleich, ob wir Unternehmens-Dashboards verwalten oder ältere Anwendungsstapel modernisieren, wir warten nicht auf automatische Warnmeldungen, die uns über ein Problem informieren. Wir fangen an, selbst nach dem Rauch zu suchen. Aber als wir uns mit dieser speziellen Sicherheitslücke beschäftigten, fanden wir etwas, das in den sensationellen Schlagzeilen übersehen wurde: Bei den meisten modernen Anwendungen war der Exploit sofort tot.

Die Anatomie des Schreckens

Die Sicherheitslücke wurde als „Gadget-Kette“ beschrieben. Wenn Sie mit dem Begriff nicht vertraut sind, stellen Sie sich das wie eine Rube-Goldberg-Maschine für Hacker vor. Es müssen verschiedene Dinge in einer bestimmten Reihenfolge schief gehen, damit die endgültige Explosion stattfindet.

Theoretisch sah die Kette so aus:

• Ein Angreifer findet einen Weg, um Ihre Anwendung durch Prototypen zu verunreinigen.

• Axios erfasst diese verschmutzten Werte, wenn es seine interne Konfiguration zusammenführt.

• Diese Werte enthalten CRLF-Zeichen (Carriage Return Line Feed), die in Header eingefügt wurden.

• Diese Header verleiten den Server zum „Anforderungsschmuggel“ oder zu einer serverseitigen Anforderungsfälschung (SSRF).

— Der Angreifer nutzt dieses SSRF, um den AWS Instance Metadata Service (IMDSv2) anzugreifen und mit Ihren Cloud-Anmeldeinformationen davonzukommen.

• Auf dem Papier ist das ein Albtraumszenario. Wenn ein Angreifer 169.254.169.254 von Ihrem Netzwerk aus erreichen kann, gehört ihm Ihre Infrastruktur. Aber hier ist der Haken: Theorie und Produktion sind zwei sehr unterschiedliche Orte.

• Warum Ihre Runtime Sie wahrscheinlich gerettet hat Als wir unser Audit durchführten, stellten wir fest, dass das Kernprinzip, auf dem dieser Exploit basiert — die CRLF-Header-Injektion — etwas ist, das Node.js seit Jahren auf Runtime-Ebene blockiert. Axios sendet keine Bytes über die Leitung selbst; es verwendet das eingebaute http-Modul in Node.js. Als wir versuchten, den Exploit in einer Standardumgebung zu reproduzieren, stießen wir immer wieder gegen eine Wand. Insbesondere ein TypeError [ERR_INVALID_CHAR] . Wenn Sie versuchen, einen Header-Wert mit einem Zeilenumbruchzeichen an http.request () zu übergeben, gibt Node.js einen Fehler aus, bevor die Anfrage Ihren Server überhaupt verlässt. Es spielt keine Rolle, wie „verschmutzt“ Ihre Axios-Konfiguration ist, wenn der zugrunde liegende Motor sich weigert zu fahren. Wir haben es überprüft und in Bun und Deno gibt es dieselben Schutzmaßnahmen. Das ist ein klassischer Fall, in dem die Bibliothek zwar technisch verwundbar ist, die Umgebung aber sicher ist. Wir haben uns sogar die Ergebnisse von Forschern wie Raul Vega Del Valle angesehen. Seine Arbeit bestätigte, was wir in unseren Labors gesehen haben: In realen Produktionsanwendungen ist es fast unmöglich, diese Kette zu erreichen, weil der Interpreter sie stoppt. Warum also die Bewertung von 10/10? Weil CVE-Werte von der schlechtesten Umgebung ausgehen, nicht von Ihrem gut gepatchten Node 20.x-Cluster.

Das gesendete Audit

Jenseits des automatisierten Scans Sie fragen sich vielleicht, warum wir uns die Mühe gemacht haben, zu patchen, wenn die Runtime den Exploit blockiert. Die Antwort ist einfach: Wir setzen nicht auf Sicherheit auf eine einzige Verteidigungsebene. Es ist eine schlechte Angewohnheit, sich auf Node.js zu verlassen, um den Fehler einer Bibliothek zu erkennen. Unser Team hat die Dateien package-lock.json und yarn.lock in jedem aktiven Projekt manuell überprüft. Wir haben nicht nur nach der Versionsnummer von axios gesucht. Wir haben uns angesehen, wie der Code tatsächlich mit dem Netzwerk interagiert. Automatisierte Tools wie Dependabot sind großartig, aber sie verstehen den Kontext nicht. Sie wissen nicht, ob Sie einen benutzerdefinierten Adapter geschrieben haben, der diese integrierten Node-Schutzmaßnahmen umgehen könnte.

• Wir haben nach benutzerdefinierten Adaptern gesucht. Wenn eine Anwendung einen benutzerdefinierten Axios-Adapter verwendet, der den http-Client von Node.js umgeht — vielleicht um Rohanfragen direkt in Sockets zu schreiben — verschwindet der Laufzeitschutz.

• Wir haben nach Prototypen von Verschmutzungsrisiken gesucht. Wenn Ihre App anfällig für die Verschmutzung durch Prototypen ist, haben Sie viel größere Probleme als nur einen Axios-Bug. Wir haben geprüft, wie wir mit JSON.parse und dem Zusammenführen von Objekten auf der ganzen Linie umgehen.

• Wir haben unsere AWS-Konfigurationen verifiziert. Selbst wenn ein SSRF aufgetreten ist, stellen wir sicher, dass unsere Projekte IMDSv2 mit strengen Hop-Limits verwenden. Dies macht den Diebstahl von Zugangsdaten selbst bei einer erfolgreichen Injektion erheblich schwieriger.

• Wir haben uns angesehen, wie Header aufgebaut sind. Wir haben nach einer Stelle gesucht, an der Benutzereingaben einen Header-Schlüssel oder -Wert berühren könnten, ohne sie zu desinfizieren.

Während dieses 24-Stunden-Fensters haben wir jedes Projekt auf Axios 1.15.0 oder höher verschoben. Wir haben gesehen, wie „Alarmmüdigkeit“ Entwicklungsteams zerstört hat. Sie erhalten einhundert Benachrichtigungen pro Woche, die meisten davon wegen Entwicklungsabhängigkeiten mit geringem Risiko, und sie beginnen, sie zu ignorieren. Wir behandeln Sicherheit als eine manuelle technische Aufgabe mit hoher Priorität, damit das Geräusch das Signal nicht übertönt.

Die chaotische Realität der Lieferkette

Diese CVE folgte auf einen weiteren, viel beängstigenderen Axios-Vorfall: einen Maintainer-Account, bei dem tatsächlich ein Remote-Access-Trojaner (RAT) eingesetzt wurde. Das war ein echter Angriff auf die Lieferkette. Es war keine „Gadget-Kette“, die vier Zufälle erforderte, um zu funktionieren; es war bösartiger Code, der in Ihrer Build-Pipeline lief.

Der Vergleich der beiden zeigt ein großes Problem in der modernen Technik. Die Branche neigt dazu, auf theoretische Fehler auf Bibliotheksebene überzureagieren, während sie auf Kontokompromittierungen zu wenig reagiert. Wir haben mehr Zeit damit verbracht, über ein theoretisches SSRF zu sprechen als über die Tatsache, dass ein Hauptbetreuer 2FA auf seinem npm-Konto nicht aktiviert hatte.

Das Delta zwischen Ihrer installierten Version und der neuesten gepatchten Version so klein wie möglich zu halten, ist die einzige Möglichkeit, gesund zu bleiben. Aber du kannst npm update nicht einfach blind ausführen. Wir haben gesehen, dass „kleinere“ Updates die Produktionsheader durchbrechen oder die Art und Weise geändert haben, wie mit Timeouts umgegangen wird. Aus diesem Grund beinhalten unsere CI/CD-Pipelines Regressionstests und Security Gates. Wenn bei einem Update ein einzelner Komponententest unterbrochen wird, geht es nicht weiter.

Wann ist ein „kritischer“ Bug nicht kritisch?

Die Bewertung „10/10" für diesen CVE basierte auf dem absoluten Worst-Case-Szenario. Wenn Sie davon ausgehen, dass ein Angreifer den Prototyp Ihrer App bereits kompromittiert hat und Sie einen seltsamen benutzerdefinierten Netzwerk-Stack verwenden und Ihre Cloud-Metadaten weit offen sind, dann ja, es ist eine 10. Aber für den durchschnittlichen Entwickler? Es ist eine Erinnerung daran, Ihre Abhängigkeiten sauber zu halten.

Wir haben ältere Projekte übernommen, bei denen die package.json seit 2022 nicht mehr angefasst wurde. Das ist eine enorme Belastung. Bei jedem veralteten Paket bleibt eine Tür offen. Wir legen Wert darauf, unsere Partner darüber aufzuklären, warum diese Audits wichtig sind. Es geht nicht darum, jeder Überschrift hinterherzulaufen; es geht darum, genau zu wissen, welcher Code in Ihrer Produktionsumgebung läuft und warum.

Und seien wir ehrlich: Axios wird langsam aufgebläht. Es ist ein großartiges Tool, aber es hat viel Legacy-Gewicht, um uralte Browser und Node-Versionen zu unterstützen. Manchmal ist die beste Sicherheitslösung kein Patch, sondern die Umstellung auf die native fetch-API, wenn Sie eine moderne Node-Runtime verwenden. Es hat weniger Funktionen, aber es hat auch eine viel kleinere Angriffsfläche.

Unser Imbiss

Sicherheit ist keine Funktion nach dem Motto „Einstellen und vergessen“. Es ist ein ständiger Überprüfungsprozess. Wir freuen uns, Ihnen mitteilen zu können, dass alle unsere internen Systeme und verwalteten Plattformen innerhalb weniger Stunden nach der Offenlegung gepatcht und verifiziert wurden, obwohl die Wahrscheinlichkeit einer tatsächlichen Ausnutzung gering ist.

Wir haben nicht nur gepatcht, weil uns die Nachricht dazu aufgefordert hat. Wir haben gepatcht, weil die Bibliothek selbst keine unsicheren Werte zulassen sollte, selbst wenn die Runtime sie abfängt. Es geht um tiefgründige Verteidigung. Wenn die erste Verteidigungslinie (Axios) ausfällt, fängt sie die zweite Zeile (Node.js) ab. Wenn die zweite fehlschlägt, blockiert die dritte (AWS IMDSv2) den Preis. So baut man Systeme, die nicht umfallen, wenn eine Bibliothek eine schlechte Woche hat.

Wenn Sie sich Sorgen um Ihren eigenen Abhängigkeitsbaum machen oder wenn Sie sich nicht sicher sind, ob Ihr aktuelles Team diese Nuancen erfasst, sollten Sie wahrscheinlich jetzt Ihre package-lock.json überprüfen. Verlassen Sie sich darauf, dass ein Bot Ihnen sagt, wenn Sie einem Risiko ausgesetzt sind, oder haben Sie ein Team, das die Laufzeit tatsächlich versteht?