Für Axios waren es ein paar chaotische Wochen.
Zunächst geriet das Paket aufgrund eines schwerwiegenden Angriffs auf die Lieferkette unter die Lupe. Nur wenige Tage später tauchten dann Schlagzeilen über eine „kritische 10/10-Sicherheitslücke“ auf, die zu einer vollständigen Kompromittierung der Cloud führen könnte.
Wenn Sie die Berichterstattung verfolgt haben, sind Ihnen wahrscheinlich Aussagen wie diese aufgefallen:
- „Angreifer können AWS-Anmeldedaten stehlen“
- „IMDSv2-Umgehung“
- „Kette zur Ausführung von Remote-Code“
Das klingt nicht gut.
Wenn man sich jedoch genauer ansieht, wie sich diese Sicherheitslücke in realen Umgebungen tatsächlich verhält, sieht die Sache schon anders aus.
Nach der Analyse der Exploit-Kette und der Überprüfung des Verhaltens gemeinsam mit Raul Vega Del Valle, dem Forscher, der den Fehler gemeldet hat, wird eines deutlich:
In Standard-Node.js-Umgebungen ist diese Sicherheitslücke realistisch gesehen nicht ausnutzbar.
Der Grund ist einfach: Der Angriff basiert auf der Einfügung fehlerhafter Header, was Node.js bereits seit Jahren auf Laufzeitebene blockiert.
Das bedeutet nicht, dass die CVE falsch ist. Das zugrunde liegende Problem bei Axios ist real, und es zu beheben, war die richtige Entscheidung. Doch die Vorstellung, dass dies zu einer einfachen Kompromittierung der Cloud in der Produktion führt, hält einer genauen Prüfung nicht stand. In der Praxis würde eine Ausnutzung sehr seltene Bedingungen erfordern, wie beispielsweise einen benutzerdefinierten Adapter, der die Header-Validierung von Node.js umgeht.
Was in der CVE behauptet wird
CVE-2026-40175 wird als „Gadget-Chain“-Sicherheitslücke beschrieben:
- Prototyp-Verunreinigung in einer Abhängigkeit
- Axios übernimmt verfälschte Werte
- CRLF-Header-Injektion
- Request-Smuggling / SSRF
- AWS IMDSv2-Umgehung
- Diebstahl von Anmeldedaten → Kompromittierung der Cloud
Theoretisch sieht das so aus:
// Prototyp-Verunreinigung an anderer Stelle
Objekt.prototype['x-amz-target'] =
"dummy\r\n\r\nPUT /latest/api/token HTTP/1.1\r\n" +
"Host: 169.254.169.254\r\n" +
"X-aws-ec2-metadata-token-ttl-seconds: 21600\r\n\r\nGET /ignore";
// Normaler Anwendungscode
axios.get("https://internal.service");Axios führt die Konfiguration zusammen → erfasst manipulierte Header → sendet eine böswillige Anfrage.
So lautet die Theorie.
Was passiert eigentlich in Node.js?
Das Problem ist: Diese Kette bricht in der Praxis.
Axios nutzt im Hintergrund den in Node integrierten HTTP-Client:
http.request(...)
Und Node.js lehnt CRLF-Zeichen in Headern schon seit Jahren ab.
Wenn Sie Folgendes versuchen:
http.request({
headers: {
"x-test": "hello\r\nInjected: yes"
}
});Sie erhalten:
TypeError [ERR_INVALID_CHAR]: Ungültiges Zeichen im Inhalt der Kopfzeile
Das geschieht, bevor eine Anfrage gesendet wird.
Die zentrale Funktion, auf der der Exploit basiert – die CRLF-Header-Injektion – wird also bereits auf Laufzeitebene blockiert.
Wir haben dies mit dem Forscher abgeklärt
Um dies zu überprüfen, haben wir direkt mit dem Forscher gesprochen, der die Sicherheitslücke gemeldet hat: Raul Vega Del Valle.
Seine Schlussfolgerung deckt sich mit unseren Beobachtungen:
- Node.js verhindert die Einfügung von CRLF-Headern
- Das gleiche Verhalten tritt auch bei Bun und Deno auf
- Folglich ist die Angriffskette in Standardumgebungen realistisch gesehen nicht durchführbar
Mit Rauls Worten:
„In der Praxis … sollte das nicht vorkommen … Node, Bun oder Deno blockieren das CRLF einfach.“
Er bestätigte außerdem, dass:
„In realen Produktionsanwendungen sollte das nicht möglich sein.“
Das ist ein entscheidender Aspekt, der in den meisten Berichten unberücksichtigt bleibt.
Warum die CVE noch immer existiert
Wenn es also in der Praxis nicht ausnutzbar ist, warum handelt es sich dann um eine CVE?
Denn das Problem besteht tatsächlich auf der Ebene der Bibliotheken.
Axios hat zuvor unsichere Header-Werte zugelassen. Selbst wenn die Laufzeitumgebung diese blockiert, hat die Bibliothek selbst diese Einschränkung nicht durchgesetzt.
Wie der Forscher erklärte:
„Auf Bibliotheksebene ist es real, auf Interpreterebene jedoch nicht“, sagt Raul Vega Del Valle
Der Vollständigkeit halber sei noch ein Sonderfall erwähnt. Axios ermöglicht es Entwicklern, die Art und Weise, wie Anfragen gesendet werden, mithilfe eines benutzerdefinierten Adapters zu überschreiben. Anstatt auf die in Node integrierte Funktion `http.request` zurückzugreifen, könnte ein benutzerdefinierter Adapter HTTP-Anfragen manuell erstellen und senden.
Theoretisch gilt: Wenn eine Anwendung:
- verwendet einen benutzerdefinierten Axios-Adapter
- umgeht den HTTP-Client von Node vollständig
- und schreibt Raw-Anfragen direkt in Sockets
Dann könnte auch die Header-Validierung umgangen werden. In diesem Fall wäre eine CRLF-Injektion möglicherweise wieder möglich.
Allerdings erfordert dies eine nicht standardmäßige Verwendung und die bewusste Deaktivierung der integrierten Schutzmechanismen. Dies gilt nicht für typische Node.js-Anwendungen, die Axios standardmäßig verwenden.
Was ist mit der IMDSv2-Umgehung?
Das ist der Teil der Geschichte, um den am meisten Wirbel gemacht wird und der am wenigsten der Realität entspricht.
Ja, in der Meldung wird eine Anfrage wie folgt angezeigt:
PUT /latest/api/token
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600
Um dies zu erreichen, benötigt ein Angreifer jedoch:
- Prototyp-Verschmutzung
- CRLF-Einschleusung
- Request-Smuggling
- keine Laufzeitvalidierung
In Node.js bricht diese Kette frühzeitig ab.
Selbst der Forscher merkte an, dass eine Umgehung von IMDSv2 in diesem Setup realistisch gesehen nicht möglich ist, wies jedoch darauf hin, dass IMDSv1 eine weitere Untersuchung wert sein könnte.
Warum dies als kritisch eingestuft wurde
Die Bewertung „10/10“ bezieht sich auf das Potenzial für Kettenangriffe im schlimmsten Fall, nicht auf die typische Ausnutzbarkeit.
Wenn man davon ausgeht, dass:
- Es besteht die Möglichkeit einer Verschmutzung durch den Prototyp
- Kopfzeilen können eingefügt werden
- interne Dienste sind erreichbar
- Metadaten-Endpunkte werden bereitgestellt
Dann könnte die Auswirkung tatsächlich schwerwiegend sein.
Aber das sind eine Menge Annahmen, die sich überschneiden.
Was Entwickler eigentlich tun sollten
Das ist zwar kein Grund, alles stehen und liegen zu lassen, aber man sollte es auch nicht einfach ignorieren.
Sie sollten:
- Aktualisieren Sie auf Axios ≥ 1.15.0
- Überprüfen Sie Ihre Abhängigkeiten auf Risiken durch Prototyp-Verunreinigungen
- Überprüfung der SSRF-Sicherheitslücke und des Netzwerkzugangs
- Verlassen Sie sich nicht ausschließlich auf Laufzeitschutzmaßnahmen
Konzentrieren Sie sich auf die tatsächliche Angriffsfläche, nicht nur auf die Schlagzeilen zu CVE.
