Ein vergifteter Prototyp kann Ihren axios-Traffic kapern. Aktualisieren Sie auf 1.18.0.

Am 1. August offenbarten die Maintainer von axios CVE-2026-67320, eine Prototype-Pollution-Schwachstelle im Node.js-HTTP-Adapter der Bibliothek. axios ist eines der meistinstallierten Pakete auf npm und betrifft damit viele Backends. Kurz zusammengefasst: Unter den richtigen Bedingungen kann ein Angreifer, der Object.prototype vergiften kann, den Server dazu bringen, seine ausgehenden HTTP-Anfragen über einen von ihm kontrollierten Proxy zu leiten. Bei unverschlüsselten http://-Aufrufen kann dieser Proxy den Authorization-Header, Basic-Auth-Anmeldedaten, die Methode, die vollständige URL, den Host-Header und den Anfrage-Body lesen – und anschließend eine selbst gewählte Antwort zurückgeben. Das NVD bewertet die Schwachstelle mit 8,3 (Hoch) auf CVSS 4.0.

Hier ist der Mechanismus – denn die Details sind entscheidend. axios schützt die zusammengeführte Anfragekonfiguration, indem es sie auf einem Null-Prototyp-Objekt aufbaut, sodass vererbte Eigenschaften nicht eingeschleust werden können. Request-Interceptors laufen jedoch nach diesem Merge, und ein sehr gebräuchliches Interceptor-Muster – return { ...config } oder Object.assign({}, config) – wandelt dieses gehärtete Objekt stillschweigend zurück in ein gewöhnliches Objekt mit Object.prototype in seiner Kette um. Der Node-Adapter liest dann config.proxy von diesem Objekt, durchläuft die Prototypkette und findet, was auch immer ein Angreifer in Object.prototype.proxy platziert hat. Der Fix in 1.18.0 liest diese verschachtelten Konfigurationswerte über einen sicheren Accessor, der vererbte Eigenschaften ignoriert.

Ein ehrlicher Vorbehalt: axios allein gibt einem Angreifer diesen Angriff nicht in die Hand. Dazu wird ein separater Prototype-Pollution-Bug irgendwo in Ihrer App oder in Ihrem Abhängigkeitsbaum benötigt, um Object.prototype.proxy überhaupt erst setzen zu können. axios ist der Verstärker, nicht der Einstiegspunkt. Genau deshalb lohnt es sich, die Sache ernst zu nehmen. Prototype-Pollution-Gadgets sind in JavaScript-Codebasen weit verbreitet, und dieser Bug verwandelt einen Befund, den viele Teams als theoretisch abtun, in eine handfeste Anmeldedaten-Exfiltration.

Dieses Muster sehen wir regelmäßig bei unseren Pentesting- und Security-Reviews. Der Scanner eines Kunden meldet ein Prototype-Pollution-Problem, jemand stuft es als „kein realer Impact“ ein – und es landet für ein Jahr im Backlog. Dann taucht ein Bug wie dieser auf, und aus dem Theoretischen wird eine direkte Verbindung zu geleakten Tokens. Prototype Pollution ist selten der komplette Exploit. Es ist das Primitive, das den nächsten Bug erheblich schlimmer macht.

Die sofortige Maßnahme ist unspektakulär – und Sie sollten sie noch heute erledigen: axios auf 1.18.0 aktualisieren, oder auf 0.33.0, wenn Sie noch die 0.x-Linie verwenden. Betroffen sind alle Versionen von 1.15.2 bis 1.18.0 sowie von 0.31.1 bis 0.33.0. Führen Sie npm ls axios aus, um jede Kopie in Ihrem Abhängigkeitsbaum anzuzeigen – einschließlich der transitiven, die Ihr eigener Code nie direkt importiert hat. Diese transitiven Kopien sind in der Regel die, die Probleme verursachen, weil niemand sie im Blick hat.

Gehen Sie dann einen Schritt weiter als der Patch. Aus unserer Arbeit mit PHP und Docker beim Aufbau cloudnativer Backends wissen wir: Die Teams, die mit solchen Meldungen gelassen umgehen, sind diejenigen, die ausgehenden Datenverkehr bereits als etwas behandeln, das es zu kontrollieren gilt – nicht nur eingehenden. Einige Maßnahmen, die sich hier auszahlen:

• Senden Sie Server-zu-Server-Anfragen grundsätzlich über https://. Dieser Bug gibt bei korrekt validiertem TLS nichts preis. Der unverschlüsselte http://-Aufruf zwischen zwei Diensten ist derjenige, der Sie in Schwierigkeiten bringt.
• Sperren Sie ausgehenden Datenverkehr. Wenn ein Dienst nur drei bekannte Hosts erreichen muss, sorgt eine Egress-Allowlist oder ein selbst betriebener Proxy dafür, dass ein gekapertes config.proxy keine nützliche Anlaufstelle hat.
• Halten Sie Geheimnisse aus URLs heraus und verkürzen Sie die Gültigkeitsdauer von allem, was Sie in internen Hops im Authorization-Header übermitteln. Kurzlebige Tokens begrenzen den Schaden, wenn doch einmal etwas durchsickert.

Es gibt auch einen Mobile-Aspekt, der leicht übersehen wird. In unseren nativen iOS- und Android-Projekten läuft axios nicht in der App selbst, wohl aber häufig im Backend-for-Frontend oder API-Gateway dahinter. Ein dort geleakter Upstream-Token kann jeden nachgelagerten Mobile-Client stillschweigend kompromittieren – und Sie werden es in den eigenen App-Logs nicht sehen. Bei der Überprüfung eines Mobile-Systems verfolgen wir den Token den gesamten Weg durch das Backend, nicht nur bis zum ersten Hop.

Die Lektion hinter diesem CVE ist die, die es sich zu behalten lohnt. Ihr Abhängigkeitsbaum ist Angriffsfläche, und „Wir nutzen diese Funktion nicht“ ist nicht dasselbe wie „Dieser Code kann nicht ausgeführt werden.“ axios hat Proxy-Unterstützung, die Sie möglicherweise nie konfigurieren – und die Schwachstelle steckte trotzdem darin. Zu wissen, was tatsächlich installiert ist, und es in einem Nachmittag patchen zu können, ist eine Fähigkeit, die Sie aufbauen, bevor Sie sie brauchen – nicht während eines Vorfalls.

Wenn Sie nicht sicher sind, was in Ihrem Abhängigkeitsbaum steckt oder wie ausgehender Datenverkehr Ihre Dienste verlässt, sprechen Sie uns an.