Es waren chaotische Wochen für Axios.
Zuerst geriet das Paket durch einen schwerwiegenden Supply-Chain-Angriff unter die Lupe. Nur wenige Tage später erschienen Schlagzeilen über eine „kritische 10/10-Schwachstelle“, die zu einer vollständigen Cloud-Kompromittierung führen könnte.
Wenn Sie die Berichterstattung gelesen haben, sind Ihnen wahrscheinlich Aussagen wie diese begegnet:
- „Angreifer können AWS-Anmeldeinformationen stehlen“
- „IMDSv2-Bypass“
- „Kette zur Remotecodeausführung“
Das klingt schlimm.
Doch bei genauerer Betrachtung, wie sich diese Schwachstelle tatsächlich in realen Umgebungen verhält, ändert sich das Bild.
Nach der Analyse der Exploit-Kette und der Validierung des Verhaltens mit Raul Vega Del Valle, dem Forscher, der das Problem gemeldet hat, wird eines klar:
In Standard-Node.js-Umgebungen ist diese Schwachstelle nicht realistisch ausnutzbar.
Der Grund ist einfach: Der Angriff hängt von der Injektion fehlerhafter Header ab, etwas, das Node.js auf Laufzeitebene bereits seit Jahren blockiert.
Das bedeutet nicht, dass die CVE falsch ist. Das zugrunde liegende Problem in Axios ist real, und das Patchen war die richtige Entscheidung. Doch die Vorstellung, dass dies zu einer einfachen Cloud-Kompromittierung in der Produktion führt, hält einer genauen Prüfung nicht stand. In der Praxis würde die Ausnutzung sehr obskure Bedingungen erfordern, wie zum Beispiel einen benutzerdefinierten Adapter, der die Header-Validierung von Node.js umgeht.
Was die CVE behauptet
CVE-2026-40175 wird als eine „Gadget-Chain”-Schwachstelle beschrieben:
- Prototype Pollution in einer Abhängigkeit
- Axios übernimmt manipulierte Werte
- CRLF-Header-Injektion
- Request Smuggling / SSRF
- AWS IMDSv2 Bypass
- Diebstahl von Zugangsdaten → Cloud-Kompromittierung
Theoretisch sieht es so aus:
// Prototype Pollution an anderer Stelle
Object.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 Konfigurationen zusammen → übernimmt manipulierte Header → sendet eine bösartige Anfrage.
Das ist die Theorie.
Was tatsächlich in Node.js passiert
Das Problem ist: diese Kette bricht in realen Umgebungen.
Axios verwendet intern Nodes integrierten HTTP-Client:
http.request(...)
Und Node.js lehnt CRLF-Zeichen in Headern seit Jahren ab.
Wenn man versucht:
http.request({
headers: {
"x-test": "hello\r\nInjected: yes"
}
});Man erhält:
TypeError [ERR_INVALID_CHAR]: Ungültiges Zeichen im Header-Inhalt
Das geschieht bevor eine Anfrage gesendet wird.
Somit ist das Kern-Primitiv, von dem der Exploit abhängt — CRLF-Header-Injection — bereits auf Runtime-Ebene blockiert.
Dies wurde mit dem Forscher verifiziert
Um dies zu validieren, haben wir direkt mit dem Forscher gesprochen, der die Schwachstelle gemeldet hat, Raul Vega Del Valle.
Seine Schlussfolgerung stimmt mit unseren Beobachtungen überein:
- Node.js blockiert CRLF-Header-Injection
- Dasselbe Verhalten tritt in Bun und Deno auf.
- Infolgedessen ist die Angriffskette in Standardumgebungen nicht realistisch erreichbar.
Mit Rauls Worten:
„In einer realen Anwendung… sollte es nicht passieren… Node, Bun oder Deno blockieren einfach das CRLF.“
Er bestätigte auch, dass:
„Es sollte in echten Produktionsanwendungen nicht möglich sein.“
Das ist eine entscheidende Nuance, die in den meisten Berichten fehlt.
Warum das CVE noch existiert
Wenn es also in der Praxis nicht ausnutzbar ist, warum ist dies ein CVE?
Weil das Problem auf Bibliotheksebene real ist.
Axios erlaubte zuvor unsichere Header-Werte. Selbst wenn die Runtime sie blockiert, hat die Bibliothek selbst diese Einschränkung nicht durchgesetzt.
Wie der Forscher erklärte:
„Es ist auf Bibliotheksebene real, wenn auch nicht auf Interpreterebene“, sagt Raul Vega Del Valle
Der Vollständigkeit halber sei auch ein Edge Case erwähnt. Axios ermöglicht es Entwickelnden, die Art und Weise, wie Anfragen gesendet werden, mithilfe eines benutzerdefinierten Adapters zu überschreiben. Anstatt sich auf Nodes integriertes http.request zu verlassen, könnte ein benutzerdefinierter Adapter HTTP-Anfragen manuell konstruieren und senden.
Theoretisch, wenn eine Anwendung:
- einen benutzerdefinierten Axios-Adapter verwendet
- Nodes HTTP-Client vollständig umgeht
- und rohe Anfragen direkt in Sockets schreibt
dann könnte auch die Header-Validierung umgangen werden. In diesem Szenario könnte CRLF-Injection wieder möglich werden.
Dies erfordert jedoch eine nicht-standardmäßige Nutzung und ein bewusstes Abwählen integrierter Schutzmechanismen. Es trifft nicht auf typische Node.js-Anwendungen zu, die Axios standardmäßig verwenden.
Was ist mit dem IMDSv2-Bypass?
Dies ist der am meisten gehypte Teil der Geschichte und der am wenigsten in der Realität verankerte.
Ja, die Empfehlung zeigt eine Anfrage wie:
PUT /latest/api/token
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600
Doch um dorthin zu gelangen, benötigt ein Angreifer:
- Prototype Pollution
- CRLF-Injection
- Request Smuggling
- keine Laufzeitvalidierung
In Node.js wird diese Kette frühzeitig unterbrochen.
Selbst der Forscher stellte fest, dass ein IMDSv2-Bypass in diesem Setup nicht realistisch umsetzbar ist, obwohl er erwähnte, dass IMDSv1 eine weitere Untersuchung wert sein könnte.
Warum dies als kritisch eingestuft wurde
Die „10/10”-Bewertung resultiert aus dem Potenzial für eine Worst-Case-Angriffskette, nicht aus der typischen Ausnutzbarkeit.
Wenn man annimmt:
- Prototype Pollution möglich ist
- Header injiziert werden können
- interne Dienste erreichbar sind
- Metadaten-Endpunkte offengelegt sind
Dann ja, könnten die Auswirkungen schwerwiegend sein.
Das sind jedoch viele Annahmen, die sich überlagern.
Was Entwickelnde tatsächlich tun sollten
Dies ist keine Situation, in der man alles stehen und liegen lassen muss, aber auch nichts, was man ignorieren sollte.
Sie sollten:
- Auf Axios ≥ 1.15.0 aktualisieren
- Ihre Abhängigkeiten auf Risiken für Prototype Pollution prüfen
- SSRF-Exposition und Netzwerkzugriff überprüfen
- Sich nicht allein auf den Laufzeitschutz verlassen
Konzentrieren Sie sich auf die reale Angriffsfläche, nicht nur auf die CVE-Überschrift.
