Sie haben das Gateway gebaut, damit kein einzelnes Notebook alle Schlüssel hält. Es hat funktioniert, und es hielt alle Schlüssel. Dann akzeptierte seine Eingangstür ein Bearer-Token, das jemand erfunden hatte.

Am 2. September hat die CISA sieben Schwachstellen aufgenommen in den Katalog der Known Exploited Vulnerabilities. Zwei SonicWall-SMA1000-Bugs, eine SQL-Injection in Sangoma Switchvox, eine Authentifizierungsumgehung in JFrog Artifactory, eine OS-Command-Injection in Kestra, eine HTTP-Smuggling-Lücke in Starlette und eine fehlerhafte Authentifizierung in BerriAIs LiteLLM.

Drei dieser sieben sind KI- und ML-Infrastruktur. Forkast nannte es den ersten KEV-Stapel, in dem KI-Komponenten fast die Hälfte der Zugänge ausmachen, die Sorte Meilenstein, die eine Schlagzeile einbringt und danach abgeheftet wird. Sehen Sie sich an, welche KI-Infrastruktur es ist, und der Stapel verdient mehr als das Abheften. Alle drei sitzen in der Mitte: Es sind die Komponenten, die Sie ausrollen, damit Ihre Agenten und die Ressourcen, die sie anfassen, nicht mehr direkt miteinander sprechen. Fangen Sie beim LiteLLM-Eintrag an.

Der Fallback-Zweig

LiteLLM ist ein KI-Gateway: ein Proxy, der zwischen Ihren Agenten und den Modellanbietern sitzt, die Anbieterschlüssel hält, damit sonst niemand es tun muss, Budgets und Ratenlimits durchsetzt, die Protokolle schreibt und inzwischen auch zu Model-Context-Protocol-Servern auffächert, sodass die Agenten eines Teams einen MCP-Endpunkt teilen, statt dass jede Entwicklerin und jeder Entwickler den eigenen verdrahtet.

CVE-2026-59822, veröffentlicht am 8. Juli und mit einem CVSS von 8.8 im GitHub-Advisory, lebt auf diesem MCP-Endpunkt. Ein Satz des Advisories trägt die ganze Geschichte:

der Fallback-Pfad konnte eine fehlgeschlagene LiteLLM-Schlüsselvalidierung durch ein leeres UserAPIKeyAuth()-Objekt ersetzen.

Der MCP-Streamable-HTTP-Endpunkt unterstützte OAuth2-Passthrough, damit ein Token für einen vorgelagerten MCP-Server durch das Gateway hindurchgereicht werden kann, statt gegen LiteLLMs eigenen Schlüsselspeicher validiert zu werden. Das ist ein sinnvolles Feature, und es braucht einen Zweig: erst den LiteLLM-Schlüssel probieren und den Passthrough-Pfad nehmen, wenn kein Schlüssel eingetroffen ist.

Man erreicht diesen Zweig durch Scheitern. Schicken Sie einen Authorization-Header mit einer beliebigen Zeichenkette, die Schlüsselprüfung weist sie zurück, weil die Zeichenkette kein Schlüssel ist, und der Handler baut ein leeres UserAPIKeyAuth() und macht damit weiter. Ihre Anfrage hält jetzt eine authentifizierte MCP-Sitzung, die niemandem gehört. Von dort aus zählen Sie jedes MCP-Werkzeug auf, mit dem das Gateway konfiguriert wurde, und rufen es auf: interne Anwendungen, Datenbanken, Cloud-Konsolen, Entwicklungssysteme, was das Team eben angeschlossen hatte. Die Lücke betrifft jede Version vor 1.84.0. Die Frist der CISA für Bundesbehörden ist der 16. September, und LiteLLMs Rat an alle, die heute nicht aktualisieren können, lautet, /mcp/ am vorgelagerten Reverse Proxy zu blockieren.

Der MCP-Handler probierte zuerst den LiteLLM-Schlüssel und nahm bei dessen Fehlschlag den OAuth2-Passthrough-Pfad, der ein leeres UserAPIKeyAuth() baute und weitermachte. Eine Anfrage mit einem erfundenen Bearer-Token landete dort, wo ein gültiger Schlüssel gelandet wäre: bei einer authentifizierten MCP-Sitzung mit der vollen Werkzeugliste des Gateways dahinter.

Die anderen drei brachen in derselben Funktion

Lesen Sie den Rest des Stapels und Sie bekommen etwas Nützlicheres als die Schlagzeile KI gegen Nicht-KI.

Starlette, CVE-2026-48710, mit dem Spitznamen BadHost. Starlette ist das ASGI-Toolkit unter FastAPI, auf dem ein großer Teil der Python-KI-Dienste aufbaut, LiteLLM eingeschlossen. Ein präparierter Host-Header schleust einen Pfad in den Host-Teil der Anfrage, was verschiebt, wie die URL rekonstruiert wird, was bedeutet, dass eine pfadbasierte Authentifizierungs-Middleware eine Route bewertet, während die Anwendung eine andere ausliefert. Der CISA-Eintrag benennt das Ergebnis: Authentifizierungsumgehung, wenn die Authentifizierung vom Pfad der rekonstruierten URL abhängt. Sie trägt einen CVSS von 6.5, den niedrigsten Wert des Stapels und den, der am wenigsten über die Folge sagt. LiteLLM lieferte einen eigenen Begleitfix für dieselbe Form in 1.84.0 und beschrieb sie als „ein präparierter Host-Header konnte das Auth-Tor des Proxys eine andere Route bewerten lassen als die ausgelieferte“, und riet Betreibern, deren Proxy exponiert war, ihre Schlüssel zu rotieren und die Verwaltungsprotokolle zu prüfen.

JFrog Artifactory, CVE-2026-82329, CVSS 9.8. Fehlerhafte Authentifizierung in der Standardkonfiguration: ein „Phantom“-Join-Key, mit dem ein nicht authentifizierter Angreifer Administrator-Tokens fälschen kann. watchTowr dokumentierte am 1. September, vier Tage nach der Offenlegung, Ausnutzung in freier Wildbahn, mit Angreifern, die Admin-Zugangsdaten prägten und Nutzer aufzählten. Das ist das Artefakt-Repository, der Host, der npm install und pip install für die ganze Organisation beantwortet.

Kestra, CVE-2026-49869. OS-Command-Injection, erreichbar für einen nicht authentifizierten entfernten Angreifer, der beliebige Workflows anlegen und ausführen kann, ganz ohne Zugangsdaten. Der Orchestrator tut, was ein Orchestrator tut — im Auftrag von jemandem, der sich nie angemeldet hat.

Vier Produkte, vier verschiedene Codebasen und dieselbe kaputte Funktion in jeder: diejenige, die entscheidet, ob diese Anfrage hier sein darf. Ein leeres Auth-Objekt. Ein rekonstruierter Pfad. Ein voreingestellter Join-Key. Bei Kestra gar keine Prüfung auf der Route, die Dinge ausführt.

Was die Angreifer danach taten, war langweilig, und die Langeweile ist das Anzeichen für Massenarbeit. The Hacker News hat das beobachtete Verhalten gesammelt: Reverse Shells, XMRig-Miner, Aufzählen von Zugangsdaten sowie Diebstahl von API-Schlüsseln und LLM-Anbieter-Zugangsdaten. Microsoft fasste es zusammen:

Die beobachteten Ziele waren durchgängig gleich. Über die Fälle hinweg zeigte die Telemetrie das Sammeln von Zugangsdaten, dauerhafte Zugangsmechanismen und Monetarisierung von Ressourcen, auch wenn der Ausführungspfad je nach Produkt verschieden war.

Vier Einträge aus einem KEV-Stapel, vier Codebasen, eine Funktion. Jedes Produkt brach an der Stelle, an der es entscheidet, ob eine Anfrage dazugehört, und drei der vier sind Komponenten, die Sie ausrollen, um Zugriff zu zentralisieren, statt jede Entwicklerin und jeden Entwickler eigene Schlüssel halten zu lassen.

Das Gateway war die richtige Idee, und das ist seine Rechnung

Das KI-Gateway ist eine der besseren Ideen der letzten zwei Jahre, und die meisten Teams sind aus guten Gründen dort gelandet.

Vor dem Gateway hielt der Coding-Agent jeder Entwicklerin und jedes Entwicklers einen Anbieterschlüssel in einer Umgebungsvariablen, jede und jeder verdrahtete eigene MCP-Server mit eigenen Tokens, und niemand konnte sagen, was das alles verbraucht oder angefasst hatte. Ein Gateway in die Mitte zu setzen, behebt das auf einen Schlag. Eine Stelle hält die Anbieterschlüssel und die MCP-Konfiguration und schreibt das Protokoll. Einen Schlüssel zu rotieren wird zu einer einzigen Operation, und eine ausscheidende Person abzuschneiden ebenso. Die Branche ist aus gutem Grund darauf zusammengelaufen.

Die Rechnung lautet: Sie haben einen Netzwerkdienst gebaut, dessen ganzer Zweck darin besteht, die Autorität für alle zu halten, und der mit einer Funktion entscheidet, wer Sie sind. Funktionen haben Zweige, und ein Zweig behandelt den Fall, dass das Erste, was Sie versucht haben, nicht funktioniert hat.

LiteLLM hat diese Form nicht erfunden. Jedes Gateway hat eine Eingangstür, jede Eingangstür hat eine Authentifizierungsfunktion, und eine Authentifizierungsfunktion, die zwei Anmeldeverfahren unterstützt, hat einen Pfad, den sie nimmt, wenn das erste scheitert. Die Reichweite hinter dieser Tür ist Absicht: Sie zu bündeln, ist das Produkt. Wenn ein Gateway also in Schwierigkeiten gerät, ist alles, was es hält, bereits im Raum.

Der übliche Schluss aus einem solchen Vorfall lautet „zurück zu Schlüsseln pro Entwickler“, und der ist nach jedem Maßstab schlechter. Zentralisieren Sie weiter. Die Frage, über die es sich zu streiten lohnt, ist, wo das zentralisierte Ding sitzt und ob es Anfragen von Fremden beantworten muss, um seine Arbeit zu tun.

Wo Bromure dieselbe Aufgabe hinlegt

Bromure Agentic Coding lässt jeden Coding-Agenten in einer hardwarevirtualisierten Linux-VM auf Ihrem eigenen Mac laufen, und jede Sicherheitskontrolle sitzt auf der Host-Seite dieser Grenze. Die Kontrollen sind dieselbe Liste, die ein Gateway bietet: Zugangsdaten halten, MCP-Server vermitteln, klassifizieren, was der Agent mit Ihrer Infrastruktur tut, den Nachweis führen. Nichts in irgendeinem Netz kann die Komponente erreichen, die sie durchsetzt.

Es gibt keine Eingangstür. Das HTTPS des Gasts verlässt ihn nie übers Netz. Es tunnelt über einen Virtio-Socket, vsock-Port 8443, zum Host-Proxy, und das Handbuch ist bei der Topologie unmissverständlich: Die VM hat keine andere Route ins Netz. Der Proxy hält keinen lauschenden Port, den Ihr LAN, Ihr Unternehmensnetz oder das Internet adressieren könnte. Er fragt nie, wer da anruft, weil ein einziges Ding am anderen Ende dieses Sockets sitzt und der Hypervisor entscheidet, was dieses Ding ist. Kein Authorization-Header, kein Schlüsselspeicher, keine Verfahrensaushandlung — und damit kein Zweig, der zu nehmen wäre, wenn das erste Verfahren scheitert.

Das MCP-Bearer-Token ist eine Attrappe, bevor es den Agenten überhaupt erreicht. Für MCP-Server mit HTTP-Transport, die in einem Workspace konfiguriert sind, bleibt das echte Bearer-Token verschlüsselt auf dem Mac. Die Konfiguration des Agenten bekommt einen brm-mcp_…-Platzhalter. Der Einstellungsbereich beschriftet dieses Feld mit Nie an die VM gesendet — vom Proxy ersetzt, und der Host-Proxy setzt den echten Wert auf der Leitung ein, begrenzt auf exakte Übereinstimmung oder Subdomain des Hosts dieses Servers und auf keinen anderen. Der Proxy beantwortet außerdem die OAuth- und OIDC-Discovery-Pfade des Servers mit 404, sodass Claude Code den Server als vorab authentifiziert behandelt, statt einen Browser-Ablauf zu versuchen, den die VM nie abschließen könnte. LiteLLMs Fallback stand auf genau dieser Passthrough-Fläche. Hier hält der Workspace keine Zugangsdaten, die er verpatzen könnte.

Jede Operation bekommt ihre eigene Entscheidung. Ein Gateway klärt die Frage an der Tür: Kommen Sie durch, gehört Ihnen alles dahinter. Bromures Guardrails klassifizieren die Aufrufe des Agenten im Proxy — über Kubernetes, AWS, Git-Forges, Container-Registries und Datenbanken hinweg — und wenden eine Schreibrichtlinie pro Dienst an. Neue Workspaces stehen standardmäßig auf Vor dem Schreiben fragen, sodass Lesezugriffe fließen und jede Änderung an einem Dialog auf der Host-Seite anhält, der die wörtliche Operation zeigt: das exakte SQL oder METHODE /pfad. Nur lesen blockiert jede Änderung. Vor der Nutzung fragen verriegelt die Zugangsdaten selbst, mit Freigaben, die in Minuten gemessen werden. Eine gefälschte Sitzung kann sich immer noch nicht per kubectl delete durch irgendetwas arbeiten, weil die zweite Entscheidung auf Ihrem Mac fällt und nichts damit zu tun hat, wie die erste ausging.

Standardmäßiges Verweigern beantwortet die Erreichbarkeit, in beide Richtungen. Die Egress-Firewall des Workspace ist eine geordnete Regeltabelle mit einem Standard für nicht zutreffenden Verkehr. Stellen Sie ihn auf Verweigern, und die VM erreicht die von Ihnen gelisteten Hosts und sonst nichts, auf jedem Protokoll. Zwei Komponenten außerhalb des Gasts setzen das durch: Der virtuelle Switch gleicht jeden Fluss nach Ziel-IP und aus dem DNS mitgelesenem Hostnamen ab, und der Proxy gleicht erneut nach dem TLS-Servernamen ab. Änderungen erreichen laufende Sitzungen ohne Neustart. In der anderen Richtung hält der NAT-Modus die VMs von Ihrem physischen LAN fern, und nichts von außen öffnet eine Verbindung zu ihnen, es sei denn, Sie veröffentlichen absichtlich einen Dienst. Die Scanner, die jene exponierten Gateways aufsammelten, bekommen von einem Mac keine Antwort.

Was ein kompromittiertes Gateway zurückschickt, ist nicht vertrauenswürdige Eingabe. Dieser Teil überdauert die CVE. Sobald ein Gateway jemand anderem gehört, kommen Modellausgaben, Werkzeugergebnisse und Fehlermeldungen alle von einem Angreifer — auf der höchstprivilegierten Leitung im Stapel: der, auf der zu handeln der Agent gebaut ist. Bromures Quellcode-Detektor bewertet tool_result-Abschnitte im ausgehenden KI-Verkehr des Agenten mit einem lokalen PromptGuard-Modell, auf dem Gerät, bevor das Modell darauf reagiert, und kann protokollieren, nachfragen oder blockieren; eine Blockade liefert HTTP 451, und das Modell sieht den Inhalt nie.

Der Exfiltrationsweg scheitert geschlossen. Jede Zugangsinformation in einem Workspace ist eine deterministische Attrappe mit genau einem legitimen Ziel. Der Proxy durchsucht jede ausgehende Anfrage nach einer Attrappe, die irgendwohin unterwegs ist, wofür sie nicht geprägt wurde; findet er eine, verweigert er die Anfrage, ohne ein Byte weiterzuleiten, pausiert die VM und löst einen Alarm aus, protokolliert als rote Zeile Credential brokering in der Security Timeline. Da nur die Attrappe je in Reichweite war, muss die echte Zugangsinformation nicht rotiert werden.

Links: Autorität in der Mitte. Ein Netzwerkdienst hält alle Schlüssel und alle MCP-Verdrahtungen, und eine einzige Authentifizierungsfunktion steht zwischen ihm und jedem, der zu ihm routen kann. Rechts: Autorität am Rand. Dieselben Kontrollen laufen auf Ihrem Mac hinter einem Hypervisor, erreicht über einen Virtio-Socket ohne lauschenden Port. Die VM hält nur Attrappen, und der Proxy entscheidet über jede Operation, nachdem die Anfrage den Gast verlassen hat.

Wenn Sie heute ein Gateway betreiben

Aktualisieren Sie LiteLLM auf 1.84.0 oder neuer; wenn das nicht geht, blockieren Sie /mcp/ am vorgelagerten Reverse Proxy. Folgen Sie dann LiteLLMs eigenem Rat aus dem Host-Header-Fix und behandeln Sie einen exponierten Proxy wie einen exponierten Schlüsselspeicher: Rotieren Sie die Anbieterschlüssel, die er hielt, und prüfen Sie die Verwaltungsprotokolle. Bundesbehörden haben bei CVE-2026-59822 bis zum 16. September Zeit — ein vernünftiges Datum zum Ausleihen.

Die Regel, die die Frage verkleinert

Setzen Sie im Guardrails-Bereich des Workspace Nicht zutreffender Verkehr auf Verweigern und listen Sie auf, was die Aufgabe braucht: allow web api.github.com, allow web registry.npmjs.org, default deny. Ein Workspace, der ein internes Gateway nicht erreichen darf, kann auch nicht genutzt werden, um durch eines hindurchzugehen, und das Speichern schiebt die Richtlinie ohne Neustart in laufende Sitzungen.

Das Geheimnis halten, nicht prüfen

Eine Zeile aus Bromures eigenen Architekturnotizen lohnt nach einer Woche wie dieser das Wiederlesen:

Die Grenze zu umgehen, bringt einem Angreifer nichts, weil die Grenze nicht der Ort ist, an dem Geheimnisse geprüft werden — sie ist der einzige Ort, an dem Geheimnisse existieren.

Ein Gateway ist ein Ort, an dem Zugangsdaten geprüft werden: Eine Anfrage trifft ein, eine Funktion inspiziert sie, und das Urteil dieser Funktion ist das Einzige, was zwischen dem Aufrufer und den Schlüsseln steht. Prüfungen haben Randfälle und Fallback-Pfade. Prüfungen bringen eine CVE, einen KEV-Eintrag und eine Bundesfrist ein — und zwei Monate später die nächste auf einem anderen Zweig derselben Funktion.

Eine Leitungsgrenze ist ein Ort, an dem Zugangsdaten sind. Nichts trifft ein, um inspiziert zu werden, also kann kein Urteil danebengehen. Das echte Token liegt verschlüsselt auf einem Mac, der Workspace hält einen brm--Platzhalter, der nirgends etwas wert ist, und die Ersetzung geschieht auf einem Socket, auf den nur ein Hypervisor schreiben kann.

Wir haben Varianten davon dreimal in sechs Wochen geschrieben: ein Egress-Proxy, der einem Hostnamen vertraute, den der Agent schreiben konnte, ein Kommando-Wächter, der bash anders las als bash, und drei Coding-Agenten, deren Umgehungen alle bei einer echten Zugangsinformation in einem Prozess endeten. Jedes Mal machte die versagende Komponente einen ehrlichen Job beim Bewerten von etwas, und das ist die Konstante. Bewertung ist ein schwächeres Primitiv als Abwesenheit, und wir übertragen der Bewertung immer weiter die Arbeit, die Abwesenheit umsonst erledigt.

Die Autorität Ihrer Agenten zu zentralisieren, war die richtige Entscheidung. Legen Sie das zentralisierte Ding dorthin, wo ihm niemand eine Anfrage schicken kann. Installieren Sie Bromure Agentic Coding und geben Sie jedem Agenten eine Grenze ohne Eingangstür.