CVE-2026-90898: KI-Gateway Bifrost führt Befehle aus

CVE-2026-90898 (CVSS 9.8), am 22. September 2026 von JFrog Security Research veröffentlicht, verwandelt eine einzige anonyme HTTP-Anfrage in Befehlsausführung auf dem Server, der das Gateway betreibt. Es braucht keine Zugangsdaten und keinen Protokoll-Handshake. Es braucht keinerlei menschliche Interaktion.

Bifrost ist ein quelloffenes KI-Gateway, das Datenverkehr an über zwanzig LLM-Anbieter weiterleitet. Die Schwachstelle betrifft alle Versionen des HTTP-Transports vor 2.1.0, sofern die Authentifizierung der Management-API abgeschaltet bleibt – also im Auslieferungszustand, wie The Hacker News^[1] berichtet.

Der Mechanismus: ein POST, ein stdio-Client, ein Befehl

Yuval Moravchick von JFrog Security Research hat den vollständigen Ablauf rekonstruiert. Ein Angreifer registriert einen MCP-Client vom Typ stdio mit einem anonymen POST an den Management-Endpunkt /api/mcp/client.

Bifrost startet den angegebenen Befehl sofort. Der Start erfolgt vor jedem Protokoll-Handshake: Das Gateway führt zuerst aus und prüft danach. Der Prozess läuft unter dem Benutzer des Gateways, der im offiziellen Docker-Image appuser heisst.

Und hier kommt der Teil, der das Risikoprofil wirklich verschiebt. Das Gateway verwahrt die API-Keys sämtlicher angebundener Anbieter, wer also Befehle innerhalb dieses Prozesses ausführt, liest diese Schlüssel aus und kauft Token auf Kosten des Unternehmens.

Eine einzige Anfrage genügt, um vom Netzwerk zum Zugangsdaten-Portfolio der gesamten Organisation zu gelangen. Die Angriffsfläche fällt mit dem Administrationsendpunkt zusammen, der mit Ausführungsrechten exponiert ist und keine Grenze zwischen der Registrierung der Komponente und dem Start des Prozesses kennt. Der Zeitverlauf der Offenlegung ist auch im öffentlichen Thread von SecOpsNews^[2] dokumentiert.

Die Zwillingslücke von Anfang September

Am 6. September 2026 hat dieselbe Forschungsgruppe CVE-2026-86242 (CVSS 8.1) veröffentlicht, entdeckt von Or Peles. Ein anonymer Angreifer registriert ein Plugin, dessen Pfad eine HTTP-URL ist.

Bifrost lädt die Datei herunter, schreibt sie als temporäres Shared Object und lädt sie mit der Go-Funktion plugin.Open. Auf dynamisch gelinkten Builds, wie sie für eigene Go-Plugins nötig sind, läuft der Code unter dem Benutzer des Gateway-Prozesses.

Auf statischen Builds, einschliesslich des offiziellen Docker-Images, schlägt plugin.Open fehl und die Auswirkung sinkt auf eine Server-Side Request Forgery. Die Korrektur kommt mit transports/v2.0.0.

Beide Schwachstellen teilen eine präzise Wurzel: Die Management-API akzeptiert die anonyme Registrierung von Komponenten, die eine Ausführungsfähigkeit mitbringen. Der Rest ist Implementierungsdetail. Eine Startfähigkeit ohne Grenzen produziert immer genau diese Klasse von Vorfall.

Exposition: Binary auf localhost, Container auf 0.0.0.0

Das Standard-Binary von Bifrost bindet die Management-API an localhost. Die Exposition bleibt auf die lokale Maschine beschränkt, und das senkt das Risiko für alle, die manuell installieren.

Das offizielle Docker-Image bindet dagegen an 0.0.0.0. Sobald der Port veröffentlicht wird, ist die Administrations-API von ausserhalb des Containers erreichbar.

Die Abweichung zwischen den beiden Standardwerten verdient Aufmerksamkeit, denn den Docker-Weg wählen in der Produktion praktisch alle. Das bequemste Deployment ist zugleich das exponierteste: ein Klassiker der agentischen Lieferkette.

Wer das Gateway mit Kubernetes orchestriert, muss die Services und Ingresses neu durchsehen, die diesen Port veröffentlichen. Eine Netzwerkregel bleibt die schnellste Verteidigung, während das Update den Release-Zyklus durchläuft, und sie kostet nur wenige Stunden Arbeit.

Versionsmatrix: welcher Patch was abdeckt

Die Abfolge der Korrekturen will genau gelesen werden, denn eine Zwischenversion lässt die Hauptlücke offen.

• Linie 1.6.x bis 1.6.11: ohne beide Korrekturen
• transports/v2.0.0: schliesst CVE-2026-86242, bleibt anfällig für die anonyme MCP-Registrierung
• transports/v2.1.0: antwortet mit 403 auf den Versuch, anonym einen MCP-stdio-Client zu registrieren

Wer auf 2.0.0 bleibt, hält sich für abgesichert und exponiert derweil weiterhin die Befehlsausführung. Es ist genau jene Art falscher Sicherheit, die einen Teil-Patch in technische Schuld verwandelt.

Für alle, die das Update aufschieben, nennt JFrog drei Massnahmen: governance.auth_config.is_enabled auf true setzen, robuste Zugangsdaten, Management-Listener ausserhalb offener Netze.

Der abschliessende Rat der Forscher ist der am schwersten verdauliche. Jede Instanz, die mit abgeschalteter Authentifizierung und erreichbarer Management-API gelaufen ist, gilt als kompromittiert – samt Rotation der Virtual Keys und der API-Keys aller angebundenen Anbieter. Die Rotation kostet wenige Stunden, gemessen an der Rechnung eines LLM-Anbieters, den Dritte wochenlang genutzt haben.

Das LLM-Gateway ist eine Control Plane

Eine Komponente, welche die Schlüssel von zwanzig Anbietern bündelt, wird zum Single Point of Compromise. Das Architekturdiagramm zeichnet sie als Routing, die operative Realität macht sie zu einer Control Plane, die Prozesse starten kann.

Die Security-Posture von KI-Systemen liegt zwei bis drei Jahre hinter der Reife der übrigen Infrastruktur zurück. Permissive Standardwerte, offene Administrationsendpunkte, zur Laufzeit geladene Komponenten: dasselbe Drehbuch wie bei den Webanwendungen der 2000er-Jahre und den APIs im Jahrzehnt danach.

Das MCP-Protokoll verstärkt die Frage, denn einen Client zu registrieren heisst, einen Prozess zu autorisieren. Wer die Registrierung als blosse Konfiguration behandelt, erhält exakt dieses Ergebnis.

Die Frage an jeden Gateway-Anbieter bleibt eine einzige: Welche Grenze trennt die Registrierung einer Komponente von ihrer Ausführung?

Drei Fragen für ein KI-Team im Unternehmen

Ein ernsthaftes Audit der Gateway-Ebene beginnt mit drei messbaren Prüfungen, abzuschliessen noch in dieser Woche.

1. Welche Version des Bifrost-Transports läuft in der Produktion, und ist die Management-API von ausserhalb des Clusters erreichbar?
2. Wurden die API-Keys der LLM-Anbieter nach der letzten Phase mit abgeschalteter Authentifizierung rotiert?
3. Welche weiteren Komponenten des agentischen Stacks akzeptieren anonyme Registrierungen mit Ausführungsfähigkeit?

Die dritte Frage bringt die unangenehmsten Überraschungen hervor. Tool-Registries, Plugin-Runner, Observability-Sidecars: etliche davon exponieren Administrationsflächen mit demselben impliziten Vertrauensmodell, das aus dem Labor stammt.

Wer alle drei mit überprüfbaren Daten beantwortet, besitzt ein Inventar. Wer aus dem Gedächtnis antwortet, besitzt eine Vermutung, und in der Sicherheit ist eine Vermutung nichts wert. Das Ergebnis gehört schriftlich festgehalten, mit Version, Datum der Prüfung und Namen der Person, welche die Verifikation zeichnet.

Entscheidungen für den nächsten Planungszyklus

Für den CTO wechselt das LLM-Gateway im Systemregister die Kategorie. Es geht von Middleware zu kritischer Komponente über, mit den Zugriffs-, Logging- und Revisionsregeln, die für einen Bastion Host gelten.

Für die Engineering-Leitung wird transports/v2.1.0 zur Mindestversion, und die erwartete Konfiguration sieht governance.auth_config.is_enabled auf true vor. Eine CI-Regel, die Images mit offenem Management blockiert, kostet einen halben Arbeitstag.

Für den CFO ist das finanzielle Risiko direkt und messbar. Gestohlene Schlüssel erzeugen abrechenbaren Token-Verbrauch, und die Kosten eines Vorfalls übersteigen die Ausgaben für einen Secret Manager und eine automatische Rotation bei Weitem.

Für das Beschaffungsgremium gehören die Verträge mit den Gateway-Anbietern in zwei Punkten überarbeitet: Disclosure-Fristen und sichere Werkseinstellungen. Ein Anbieter, der die Authentifizierung abgeschaltet ausliefert, lädt seine technische Schuld beim Kunden ab.

Bifrost bleibt ein ernstzunehmendes Projekt, mit einem Team, das eigene Lücken behebt und dokumentiert. Das Urteil betrifft die Werkskonfiguration, und die gehört vor dem nächsten Deployment geändert.