BadHost: Ein Host-Header brach die Auth im KI-Stack

BadHost, geführt als CVE-2026-48710, ist eine Host-Header-Authentifizierungsumgehung in Starlette, dem Python-ASGI-Framework, das unter FastAPI und damit unter einem großen Teil der heutigen KI-Infrastruktur sitzt. Starlette validiert den HTTP-Host-Header nicht gegen die URL-Grammatik, bevor es ihn zur Rekonstruktion der Request-URL nutzt. Ein Host-Wert mit einem Schrägstrich, Fragezeichen oder Hash verschiebt beim erneuten Parsen, wo die Grenzen von Pfad, Query und Fragment fallen, sodass pfadbasierte Middleware ihre Zugriffsentscheidung gegen einen Pfad trifft, der nicht mehr zu der Route passt, die der Server tatsächlich ausführt. Das Ergebnis ist stumpf: Ein fehlerhafter Header überspringt eine pfadbasierte Auth-Prüfung, während die geschützte Route weiterläuft.

Die Reichweite ist der Teil, der Sie beunruhigen sollte. Starlette hat 325 Millionen wöchentliche Downloads und trägt vLLM, FastAPI-Dienste, LLM-Proxy-Ebenen und Model-Context-Protocol-Server. Wenn Sie eines davon betreiben, haben Sie diese Abhängigkeit nicht gewählt, aber ihr Vertrauensmodell geerbt. Dies ist die Einordnung von jemandem, der solche Systeme baut und härtet, kein Nacherzählen des Advisories.

Was BadHost tatsächlich tut

Der Mechanismus ist fast beleidigend klein. Wenn ein Request ankommt, rekonstruiert Starlette aus dem Host-Header eine URL, um request.url zu füllen. Der Host-Wert wurde nie gegen die RFC-Grammatik für einen Host geprüft, sodass ein Angreifer einen Host wie evil.com/admin? senden kann und der Parser die Grenze zwischen Authority und Pfad falsch setzt. Middleware, die den Zugriff an request.url.pathfestmacht, inspiziert nun einen Pfad, der sich von dem unterscheidet, den der ASGI-Server geroutet hat. Die Sicherheitsprüfung besteht gegen die falsche Zeichenkette, während der echte Handler auf der richtigen läuft.

Das ist keine neuartige KI-Schwachstelle. Es ist ein Lehrbuch-Kanonisierungsfehler, dieselbe Klasse wie die Host-Header- und Request-Smuggling-Angriffe, die die Web-Sicherheit seit fünfzehn Jahren dokumentiert, aufgetaucht in einem Framework, das schneller tragend für KI wurde, als sein Sicherheitsmodell reifte. Gefunden wurde der Fehler von X41 D-Sec beim Audit von vLLM unter einem OSTIF-Förderprogramm und in Starlette 1.0.1 behoben. Der Haken ist das Offenlegungsfenster: Rund ein Tag verging zwischen dem korrigierten Release auf PyPI und der Veröffentlichung, sodass Scanner und Korrektur im selben Moment in den Händen von Angreifern wie Verteidigern lagen.

Warum der KI-Stack härter getroffen wird als eine generische Web-App

Jede FastAPI-App ist im Prinzip exponiert, aber KI-Infrastruktur trägt drei Eigenschaften, die BadHost schlimmer machen als einen routinemäßigen Middleware-Bug. Die Komponenten unten sitzen alle auf Starlette, und jede macht aus der Umgehung mehr als einen übersprungenen Login.

Die MCP-Zeile ist die, die man zweimal lesen sollte. Die Model-Context-Protocol-Spezifikation verlangt einen unauthentifizierten OAuth-Discovery-Endpunkt, was einem Angreifer einen vorhersehbaren, stets vorhandenen Ort liefert, auf den er die Umgehung richtet. Ein Framework-Bug plus ein Protokoll, das eine unauthentifizierte Fläche einbaut, ist eine schlimmere Kombination als jedes für sich, und sie landet genau dort, wo Agenten nach ihren Tools greifen. Die Orchestrierungsfolgen davon sind dieselben, die ich in was bei der Agenten-Orchestrierung im Produktionsmaßstab bricht behandelt habe.

Dieses Bedrohungsmodell ist nicht hypothetisch

Es wäre einfach, BadHost als unwahrscheinlichen Bug abzulegen, weil die Ausnutzung ein pfadbasiertes Tor zum Umgehen braucht. Dieser Trost übersteht nicht den Kontakt mit dem, was Angreifer exponierter KI-Infrastruktur bereits antun. Am 10. Mai 2026, Wochen bevor BadHost offengelegt wurde, dokumentierte Sysdig das erste von einem LLM-Agenten gesteuerte Eindringen in freier Wildbahn. Der Angriff nutzte einen anderen Bug, CVE-2026-39987 im Marimo-Notebook-Server, aber die Form ist die Warnung, die für BadHost zählt.

In jenem Vorfall arbeitete der Agent autonom: Er nahm eine Pre-Authentication-Remote-Code-Ausführung auf einem exponierten Notebook, zog Cloud-Anmeldedaten aus Umgebungsdateien, verteilte zwölf API-Aufrufe über elf IP-Adressen in zweiundzwanzig Sekunden, um Rate-Limiting auszuweichen, holte einen SSH-Schlüssel aus dem AWS Secrets Manager und kippte eine interne PostgreSQL-Datenbank, schloss die Exfiltration in unter zwei Minuten und die ganze Kette in unter einer Stunde ab. Die Lehre ist nicht das Marimo-CVE. Sie ist, dass ein unauthentifizierter Bug auf exponierter KI-Infrastruktur jetzt von autonomem Tooling in Maschinengeschwindigkeit waffenfähig gemacht wird, genau die Lage, in die BadHost einen Starlette-basierten Dienst bringt.

Was diese Woche zu tun ist

Die Korrektur ist teils ein Patch und größtenteils eine Gewohnheit. Jeder Schritt unten ist für sich nützlich, und die Reihenfolge ist bewusst gewählt.

1. Pinnen Sie Starlette auf 1.0.1 oder höher über jeden Dienst, der davon abhängt, direkt oder transitiv. Die Falle ist der transitive Fall: Sie betreiben Starlette womöglich, ohne es zu wissen, unter FastAPI, vLLM oder einem MCP-Server.
2. Inventarisieren Sie die versteckte Abhängigkeit. Erstellen Sie eine Software-Stückliste für Ihre KI-Dienste, damit Sie beantworten können, welche davon Starlette ausliefern, so wie Sie erfassen würden, welche Hosts einen exponierten Dienst betreiben.
3. Authentifizieren Sie nicht gegen angreifergesteuerte Eingaben. Behandeln Sie den Host-Header und jeden daraus abgeleiteten Pfad als nicht vertrauenswürdig, bis validiert und kanonisiert. Treffen Sie Sicherheitsentscheidungen gegen eine Identität, die Sie verifiziert haben, nicht gegen eine Zeichenkette, die der Client setzte.
4. Vertrauen Sie auch X-Forwarded-Host nicht. Die sekundäre Umgehung nutzt ihn, um die Bereinigung an einem nginx- oder AWS-Load-Balancer zu besiegen, also ist ein sauberer Reverse-Proxy kein Ersatz für den Patch.
5. Fügen Sie Tiefenverteidigung hinzu. Default-Deny-Egress um die Laufzeit und Least-Privilege-Tool-Anmeldedaten bedeuten, dass ein umgangenes Tor trotzdem wenig erreicht, dieselbe Härtung, die ich für selbst-gehostete KI-Infrastruktur beschrieben habe.

Wenn Sie Ihre KI-Dienste containerisieren, ist der Build der natürliche Ort, die Patch-Untergrenze und die Egress-Richtlinie zu erzwingen, weshalb die Deployment-Muster in Docker für produktive KI für BadHost mehr tun als jede einzelne Code-Änderung. Pinnen Sie die Abhängigkeit im Image, verweigern Sie Egress in der Netzwerk-Richtlinie, und ein künftiger Framework-Bug hat einen viel kleineren Schadensradius, bevor Sie sein CVE überhaupt gelesen haben.

Das Muster, nicht der Patch

BadHost wird gepatcht und vergessen, und ein anderer Framework-Bug nimmt seinen Platz ein, denn der zugrunde liegende Fehler ist älter als der KI-Stack und wird immer wieder eine Schicht höher neu gebaut. Die Lehre, die es zu behalten gilt, ist die Regel, auf die sowohl dieser Bug als auch das Agenten-Bedrohungsmodell zeigen: Ein KI-System ist eine Sicherheitsgrenze, und die Eingabe, die es erreicht, ein Host-Header, ein abgerufenes Dokument, ein Tool-Argument, ist feindlich, bis das Gegenteil bewiesen ist. Das ist dieselbe Grenze, die eine Retrieval-Pipeline gegen Prompt Injection verteidigt, und dieselbe Disziplin hinter dem Messen der echten Angriffserfolgsrate eines Agenten. Validieren Sie die Eingabe, begrenzen Sie das Privileg, und nehmen Sie an, dass das Tor eines Tages falsch liegt.

Weiterführende Lektüre: siehe selbst-gehostete KI-Infrastruktur absichern, wie der Agenten-Skill-Marktplatz vergiftet wurde, RAG-Pipelines gegen Prompt Injection absichern und Docker-Muster für produktive KI.