Sicherheitslücke in Starlette erlaubt Authentifizierungs-Bypass bei FastAPI-Apps mit pfadbasierter Authentifizierung

Sicherheitsforscher von X41 D-Sec entdeckten im Rahmen eines von OSTIF finanzierten Audits des vLLM-Inference-Frameworks eine kritische Sicherheitslücke in Starlette – dem Python-ASGI-Framework, das FastAPI und ein breites Ökosystem von AI-Agent-Infrastruktur unterstützt. Die Schwachstelle, als CVE-2026-48710 geführt und BadHost getauft, erlaubt es einem Angreifer, den HTTP-Host-Header zu manipulieren, sodass Starlette einen anderen URL-Pfad meldet, als der Webserver tatsächlich geroutet hat – und damit jede Middleware umgeht, die request.url.path für Zugriffsentscheidungen verwendet. Der Fix ist in Starlette 1.0.1 verfügbar.

Das Gefährdungspotenzial ist groß. Starlette hat über 400.000 Abhängigkeiten auf GitHub und mehr als 325 Millionen wöchentliche Downloads auf PyPI. Betroffen sind alle Anwendungen, die auf FastAPI mit pfadbasierter Authentifizierungs-Middleware aufbauen, sowie eine Reihe von KI-Infrastruktur-Tools: vLLM, LiteLLM, Model Context Protocol (MCP)-Server, FastMCP, Googles ADK-Python, Ray Serve und BentoML sind alle verwundbar, wenn eine benutzerdefinierte Auth-Middleware eingesetzt wird.

Wie der Angriff funktioniert

HTTP-Anfragen enthalten einen Host-Header, der die Zieldomain identifiziert. Starlette konstruiert sein request.url-Objekt, indem es den rohen Host-Header mit dem Anforderungspfad verkettet und den resultierenden String dann erneut als URL parst. Das Problem: Starlette hat vor dieser Konstruktion nicht geprüft, ob der Host-Header der RFC-9112-Grammatik entspricht. Ein Angreifer kann Pfad-Trennzeichen – /, ? oder # – in den Host-Header injizieren, was den Parser dazu bringt, einen anderen Pfad, Query-String oder Fragment zu sehen, wenn er die zusammengesetzte URL erneut analysiert.

Das Ergebnis ist eine gespaltene Sicht: Der ASGI-Server routet die Anfrage an den tatsächlichen Pfad (etwa /admin), aber request.url.path – das, was die Authentifizierungs-Middleware ausliest – meldet stattdessen den vom Angreifer kontrollierten Pfad (/health oder einen anderen harmlosen Pfad, den die Middleware passieren lässt). Das X41-Advisory enthält einen Proof-of-Concept so einfach wie:

curl -H 'Host: foo?' localhost:8000/admin

Auf einem verwundbaren Server mit pfadbasierter Authentifizierung liefert dies einen 200 OK vom geschützten Endpunkt /admin statt eines 403 Forbidden.

Der Grund, warum die Schwachstelle so lange unentdeckt blieb, ist, dass sie aus dem Zusammenspiel dreier Schichten entsteht, die jeweils für sich betrachtet vernünftig erscheinen: ASGI-Server geben den rohen Host-Header ohne Validierung weiter; Starlette vertraut ihm bei der URL-Konstruktion; und Middleware-Entwickler gehen davon aus, dass request.url.path ein sicherer, server-autoritativer Wert für Zugriffskontrollen ist. Keine einzelne Schicht ist für sich genommen fehlerhaft.

Wer ist betroffen

Die Schwachstelle ist vor allem für Anwendungen relevant, die den Zugang zu geschützten Endpunkten über eine Middleware regeln, die den Anfragepfad prüft. Dies ist ein gängiges Muster in FastAPI-Anwendungen, bei denen ein Pfadpräfix (wie /admin, /internal oder /v1/private) die Autorisierung bestimmt. Anwendungen, die FastAPIs eingebaute Depends()- oder Security()-Dekorateure auf Routenebene verwenden, sind in der Regel nicht betroffen, da diese Mechanismen die Autorisierung zum Zeitpunkt der Routenauflösung prüfen und nicht über eine Pfadinspektion in der Middleware.

Die Auswirkungen auf die KI-Infrastruktur sind der größte Grund zur Besorgnis. MCP-Server – die das Model Context Protocol für die Verbindung von AI-Agents mit Tools und Datenquellen implementieren – sind besonders exponiert, weil die MCP-Spezifikation unauthentifizierte OAuth-Discovery-Endpunkte vorschreibt, wodurch Angreifer einen bekannten, zuverlässigen Bypass-Pfad haben, ohne erraten zu müssen, welche Pfade ungeschützt sind. vLLM und LiteLLM, die in der Produktion häufig zum Ausliefern und Proxying großer Sprachmodelle (LLMs) eingesetzt werden, sind betroffen, wenn sie hinter benutzerdefinierter Starlette-basierter Authentifizierungs-Middleware sitzen. Auch Googles ADK-Python, das Python-SDK zum Erstellen von AI-Agents mit Googles Modellen, steht auf der Liste der betroffenen Komponenten.

Behebung

Die primäre Lösung ist das Upgrade auf Starlette 1.0.1, das Host-Header mit ungültigen Zeichen ablehnt, anstatt sie für die URL-Konstruktion zu verwenden. Für Anwendungen, die nicht sofort aktualisieren können, besteht die Abschwächung darin, jede Verwendung von request.url.path in Authentifizierungs- oder Autorisierungs-Middleware durch scope["path"] zu ersetzen – den ASGI-Scope-Pfad, der direkt aus der HTTP-Anfragezeile stammt und nicht vom Host-Header beeinflusst wird. Die längerfristige Empfehlung lautet, pfadbasierte Authentifizierung in Middleware ganz zu vermeiden und stattdessen auf FastAPIs routenbasierte Depends()- und Security()-Mechanismen zu setzen.

Das Forschungsteam hat zusammen mit der Offenlegung Erkennungstools veröffentlicht: Semgrep-Regeln, CodeQL-Abfragen für die statische Analyse und einen kostenlosen Scanner auf badhost.org, der Endpunkte direkt testen kann. Der Scanner unterstützt drei Modi – MCP-spezifisch, automatische Erkennung von KI-Infrastruktur und benutzerdefinierte Pfad-Tests – sodass Teams ihre Gefährdung einschätzen können, ohne das Advisory vollständig lesen zu müssen.

CVE-2026-48710 wurde am 27. Januar 2026 entdeckt und koordiniert am 21.–22. Mai 2026 öffentlich gemacht, nach dem Patch in Starlette 1.0.1. Vollständige technische Details finden sich im X41-Advisory unter x41-dsec.de.