BadHost zeigt, wie fragil viele KI-Agenten-Server sind

Worum es geht

Starlette, ein leichtgewichtiges Python-ASGI-Framework und Basis vieler FastAPI-Dienste, hat eine Sicherheitslücke mit dem Namen BadHost. Die Lücke wird als CVE-2026-48710 und GHSA-86qp-5c8j-p5mr geführt. Öffentlich detailliert wurde sie am 26. Mai 2026 unter anderem von OSTIF, Secwest und Ars Technica; Gigazine griff den Fall am 27. Mai 2026 auf.

Das Thema ist nicht deshalb spannend, weil ein weiteres Webframework gepatcht werden muss. Es ist spannend, weil Starlette unter einem großen Teil der Python-Infrastruktur liegt, die heute für LLM-Gateways, vLLM-Server, LiteLLM-Proxys, MCP-Server, Evaluations-Dashboards und interne Agenten-UIs genutzt wird. Genau dort liegen oft API-Schlüssel, Mailbox-Zugriffe, Modellverwaltungsrechte oder Tool-Ausführungen.

Was BadHost tatsächlich macht

BadHost nutzt aus, dass betroffene Starlette-Versionen den HTTP-Host-Header nicht streng genug validieren, bevor daraus request.url rekonstruiert wird. Der Router entscheidet über den echten Pfad der Anfrage. Middleware oder Endpunkte können aber request.url.path sehen, also einen aus dem manipulierten Host-Header neu zusammengesetzten Pfad.

Wenn Sicherheitslogik in Middleware auf request.url.path vertraut, kann ein Angreifer mit einem speziell geformten Host-Header erreichen, dass die Kontrolle einen harmlosen Pfad sieht, während der Router trotzdem den eigentlich geschützten Pfad ausführt. Secwest beschreibt den Kern als Ein-Zeichen-Primitiv: Schon ein Zeichen wie ?, / oder # im Host-Header kann die Interpretation verschieben.

Laut Advisory sind Anwendungen betroffen, wenn sie eine verwundbare Starlette-Version nutzen und sicherheitsrelevante Entscheidungen auf Basis von request.url oder request.url.path treffen. Ein korrekt konfigurierter Reverse Proxy kann entschärfen, wenn er fehlerhafte Host-Header verwirft. Das gilt aber nicht automatisch für jede Labor-, Dev- oder interne Agenten-Installation.

Warum das wichtig ist

Starlette selbst ist ein allgemeines Webframework. Der neue Risikokern liegt in der Abhängigkeit: FastAPI baut darauf auf, und FastAPI ist in vielen KI-Stacks die schnelle Standardschicht für APIs. Secwest nennt als bekannte betroffene Ökosysteme unter anderem vLLM, LiteLLM, Text Generation Inference, OpenAI-kompatible Proxy-Projekte, MCP-Server, Agent-Harnesses, Eval-Dashboards und Modellverwaltungsoberflächen.

Ars Technica berichtet, dass Starlette laut Entwicklerangaben rund 325 Millionen Downloads pro Woche erreicht. Diese Zahl ist kein Beweis für 325 Millionen verwundbare Server. Sie zeigt aber, wie breit die Komponente verteilt ist. Gerade bei KI-Diensten ist der Schaden ungewöhnlich konkret: Ein geschützter Endpunkt kann Modell-Uploads, Admin-Funktionen, API-Key-Verwaltung oder Tool-Ausführung enthalten.

Für echte Menschen bedeutet das: Ein scheinbar kleiner HTTP-Parsing-Fehler kann dazu führen, dass ein Agenten-System nicht nur Daten liest, sondern über angebundene Tools handelt. Bei MCP-Servern kann das E-Mail, Kalender, Datenbanken, Cloud-Metadaten oder interne Dokumente betreffen.

Einfach erklärt

Stell dir ein Bürogebäude mit zwei Schildern vor. Der Sicherheitsdienst schaut auf das Schild am Empfang und sagt: „Das ist nur der Besucherbereich.“ Der Fahrstuhl orientiert sich aber an einem zweiten, internen Schild und fährt trotzdem in den Serverraum.

BadHost ist genau diese Verwechslung: Ein Teil der Anwendung prüft einen rekonstruierten Pfad, ein anderer Teil führt den echten Pfad aus. Wenn die Türkontrolle und die Wegführung unterschiedliche Karten lesen, reicht ein kleiner Trick auf dem Schild, um an der falschen Stelle zu landen.

Praktisches Beispiel

Ein Team betreibt einen internen LiteLLM-Proxy auf ai-gateway.example.com. Der Proxy verarbeitet 120.000 API-Anfragen pro Tag und hat ein internes Admin-Panel unter /admin, in dem Modellrouten, Budgets und API-Schlüssel verwaltet werden. Eine FastAPI-Middleware blockiert /admin, indem sie request.url.path prüft.

Wenn der Dienst direkt über uvicorn erreichbar ist und eine verwundbare Starlette-Version nutzt, könnte ein Angreifer einen manipulierten Host-Header senden. Die Middleware glaubt, sie prüfe einen erlaubten Pfad, während Starlette den Request an /admin routet. Der konkrete Schaden hängt vom Admin-Panel ab: Sichtbare Schlüssel, geänderte Modellrouten oder im schlimmsten Fall Tool-Ausführung.

Die pragmatische Reaktion wäre: Starlette auf 1.0.1 oder höher bringen, Container neu bauen, alle gebündelten Python-Umgebungen prüfen, Host-Header am Reverse Proxy hart validieren und in Middleware für Sicherheitsentscheidungen nicht request.url.path, sondern den rohen ASGI-Pfad aus scope["path"] verwenden.

Einordnung und Grenzen

• Nicht jede Starlette- oder FastAPI-Anwendung ist automatisch kompromittiert. Entscheidend ist, ob verwundbare Versionen laufen und ob Sicherheitslogik auf request.url oder request.url.path basiert.
• Ein sauber konfigurierter Reverse Proxy kann den Angriff blockieren, wenn er malformed Host-Header wirklich verwirft. Betreiber sollten das testen, nicht nur annehmen.
• Die öffentlich genannten Auswirkungen wie SSRF oder RCE sind Folgeketten. Sie entstehen nur, wenn hinter dem umgangenen Pfad Funktionen liegen, die Netzwerkanfragen, Codeausführung, Modell-Downloads oder Tool-Aufrufe erlauben.

BadHost ist kein Beweis, dass „KI-Agenten unsicher“ sind. Es ist ein Beweis, dass Agenten-Infrastruktur oft alte Web-Sicherheitsprobleme mit neuen Rechten kombiniert. Das macht aus einem Header-Bug ein echtes Betriebsrisiko.

SEO- und GEO-Schlüsselbegriffe

BadHost, CVE-2026-48710, Starlette, FastAPI, MCP Server, LiteLLM, vLLM, AI agent security, Host header vulnerability, Python ASGI, LLM gateway security, request.url.path