Bifrost: Kritische Lücke CVE-2026-90898 erlaubt Befehlsausführung ohne Anmeldung

Wer das quelloffene KI-Gateway Bifrost im offiziellen Docker-Image betreibt und die Management-Authentifizierung nie aktiviert hat, sollte heute handeln. Eine kritische Lücke mit der Kennung CVE-2026-90898 (CVSS 9.8) erlaubt es, über eine einzige unauthentifizierte HTTP-Anfrage beliebige Befehle auf dem Gateway-Server auszuführen. Betroffen sind alle Versionen des Bifrost-HTTP-Transports vor transports/v2.1.0, sobald die Management-Authentifizierung deaktiviert ist. Genau das ist die Standardkonfiguration.

Nicht betroffen ist, wer bereits transports/v2.1.0 einsetzt oder wer die Authentifizierung über governance.auth_config.is_enabled aktiviert hat. Wer das reine Bifrost-Binary ohne Container nutzt, hat etwas mehr Luft: Dort lauscht die Management-API standardmäßig nur auf localhost, die Gefährdung bleibt also lokal. Im offiziellen Docker-Image bindet der Dienst dagegen an 0.0.0.0. Sobald der Port veröffentlicht wird, ist die Management-API von außen erreichbar. Das ist der zentrale Praxispunkt für Administratoren.

Was ist passiert?

Bifrost ist ein KI-Gateway, das Anfragen an mehr als 20 LLM-Anbieter weiterleitet und dabei die Zugangsdaten für all diese Anbieter zentral vorhält. Yuval Moravchick von JFrog Security Research hat darin eine unauthentifizierte Befehlsausführung gefunden. Der Ablauf ist denkbar kurz: Ein Angreifer schickt einen einzigen POST ohne jede Anmeldung an den Management-Endpunkt /api/mcp/client und registriert dort einen MCP-Client vom Typ stdio.

Bifrost startet den in dieser Registrierung angegebenen Befehl sofort, und zwar noch bevor irgendein MCP-Handshake stattfindet. Der Befehl läuft mit den Rechten des Gateway-Prozesses. Im offiziellen Docker-Image ist das der Benutzer appuser. Da das Gateway die API-Schlüssel sämtlicher angebundener Anbieter speichert, öffnet die Befehlsausführung direkt den Weg zu diesen Zugangsdaten. Aus einer Gateway-Übernahme wird damit sehr schnell ein Abfluss fremder Anbieter-Schlüssel, für die anschließend auf Kosten des Betreibers Anfragen gestellt werden können.

Behoben ist das Verhalten in transports/v2.1.0. Diese Version beantwortet den Versuch, ohne Authentifizierung einen stdio-MCP-Client zu registrieren, mit HTTP 403.

Wer ist betroffen?

Die Betroffenheit lässt sich an drei Punkten festmachen, die gemeinsam erfüllt sein müssen, damit es kritisch wird.

• Version des HTTP-Transports älter als transports/v2.1.0. Alle älteren Stände enthalten die MCP-Lücke.
• Management-Authentifizierung deaktiviert, also governance.auth_config.is_enabled nicht auf true gesetzt. Das ist der Auslieferungszustand.
• Management-Listener aus einem nicht vertrauenswürdigen Netz erreichbar. Im Docker-Image ist das nach einer Portfreigabe der Regelfall, beim nackten Binary standardmäßig nicht.

Wichtig für die Versionsplanung: transports/v2.0.0 ist von der MCP-Lücke weiterhin betroffen. Diese Version hat lediglich eine ältere Plugin-Schwachstelle geschlossen. Die Reihe 1.6.x bis einschließlich 1.6.11 enthält keinen der beiden Fixes. Wer also nur von 1.6.x auf 2.0.0 aktualisiert hat und den Fall damit als erledigt betrachtet, liegt falsch.

Es gibt eine zweite Schwachstelle mit derselben Wurzel. CVE-2026-86242 (CVSS 8.1), gefunden von Or Peles und am 06.09.2026 veröffentlicht, erlaubt es einem unauthentifizierten Angreifer, ein eigenes Plugin zu registrieren, dessen Pfad eine HTTP-URL ist. Bifrost lädt die Datei herunter, schreibt sie als temporäre Shared-Object-Datei und lädt sie über Gos plugin.Open. Bei dynamisch gelinkten Builds, wie sie Bifrost für eigene Go-Plugins ohnehin braucht, läuft der eingeschleuste Code als Gateway-Benutzer. Bei statisch gelinkten Builds, darunter das offizielle Docker-Image, scheitert plugin.Open, es bleibt dort Server-Side Request Forgery. Behoben ist diese Lücke in transports/v2.0.0.

Wie kritisch ist das?

Technisch handelt es sich bei CVE-2026-90898 um eine unauthentifizierte Remote Code Execution ohne jede Vorbedingung außer Netzwerkerreichbarkeit. Der CVSS-Wert von 9.8 ist entsprechend, und der Angriffspfad ist so kurz, dass er sich trivial automatisieren lässt. Für eine exponierte Instanz ist das ein akutes Problem, kein Thema für das übernächste Wartungsfenster.

Gleichzeitig gehört zur ehrlichen Einordnung, dass keine der beiden Bifrost-Schwachstellen im KEV-Katalog der US-Behörde CISA steht und es bislang keinen Hinweis auf aktive Ausnutzung gibt. Wer intern priorisiert, sollte das so weitergeben: hohe technische Schwere und sehr niedrige Angriffshürde, aber keine bestätigte laufende Kampagne. Das rechtfertigt schnelles Handeln, nicht jedoch eine Notfallkommunikation mit Bedrohungslage.

Der Vergleich liegt trotzdem nahe: Eine ähnliche Befehlsinjektion im KI-Gateway LiteLLM wurde aktiv ausgenutzt und im Juni in den CISA-KEV-Katalog aufgenommen. Zusätzlich wurde im April 2026 ein Designfehler im STDIO-Transport von MCP offengelegt, der auch die offiziellen SDKs von Anthropic betrifft. Die Klasse der Angriffe ist also bekannt und wird von Angreifern bereits bedient.

Ein zweiter Punkt betrifft den Schaden nach einer erfolgreichen Ausnutzung. Ein KI-Gateway ist per Definition ein Schlüsselspeicher. Wer die Kontrolle über den Prozess erlangt, hat Zugriff auf die virtuellen Schlüssel der internen Nutzer und auf die echten Anbieter-Schlüssel. JFrog empfiehlt deshalb ausdrücklich, jede Instanz, die mit deaktivierter Authentifizierung und exponierter Management-API lief, als kompromittiert zu behandeln.

Was sollten Admins jetzt tun?

• Bestand prüfen: Laufen im Unternehmen Bifrost-Instanzen, und in welcher Version? Maßgeblich ist der Stand des HTTP-Transports, also transports/v2.1.0 als Zielmarke. Ein Update von 1.6.x auf 2.0.0 reicht ausdrücklich nicht.
• Konfiguration prüfen: Steht governance.auth_config.is_enabled auf true? Wenn das Feld nie gesetzt wurde, ist die Management-API offen.
• Exposition prüfen: Welche Ports veröffentlicht der Container, und ist der Management-Listener aus dem internen Netz oder gar aus dem Internet erreichbar? Beim Docker-Image bindet der Dienst an 0.0.0.0.
• Auf transports/v2.1.0 aktualisieren. Das ist die einzige vollständige Lösung für beide beschriebenen Lücken.
• Wenn ein sofortiges Update nicht möglich ist: Authentifizierung aktivieren, starke Zugangsdaten vergeben und den Management-Listener über Firewall oder Reverse Proxy aus nicht vertrauenswürdigen Netzen heraushalten.
• Logs sichten: Gab es POST-Anfragen auf /api/mcp/client oder auf die Plugin-Registrierung, die nicht aus der eigenen Administration stammen? Unerwartete Kindprozesse des Gateway-Prozesses sind ebenfalls ein Indikator.
• Bei Verdacht oder bei belegter Exposition ohne Authentifizierung: virtuelle Schlüssel und alle Anbieter-API-Schlüssel rotieren, nicht nur den vermeintlich betroffenen.
• Abrechnungsdaten der angebundenen LLM-Anbieter auf ungewöhnliche Nutzungsspitzen prüfen. Gestohlene Schlüssel fallen dort oft zuerst auf.
• Nach dem Update gegenprüfen, dass eine unauthentifizierte Registrierung eines stdio-MCP-Clients tatsächlich mit HTTP 403 beantwortet wird.
• Den Management-Port dauerhaft vom Datenpfad trennen, also nicht gemeinsam mit dem eigentlichen Inferenz-Endpunkt veröffentlichen.

Einordnung für Unternehmen

Der eigentliche Befund dieser Meldung ist weniger die einzelne Lücke als das Muster dahinter. Beide Bifrost-Schwachstellen haben dieselbe Ursache: Die Management-API wird mit deaktivierter Authentifizierung ausgeliefert. Es sind die zweite und dritte Sicherheitsmeldung des Projekts innerhalb von weniger als einem Monat. Davor gab es bereits eine nicht verwandte SSRF-Lücke, CVE-2026-55245, die Ende August 2026 behoben wurde.

Für kleinere IT-Abteilungen heißt das praktisch: KI-Gateways sind inzwischen ein eigenständiges Angriffsziel und sollten wie ein Secrets-Management-System behandelt werden, nicht wie ein beliebiger interner Dienst. Konkret bedeutet das eine getrennte Netzzone, keine Veröffentlichung der Management-Oberfläche, Authentifizierung als Pflicht statt als Option und ein dokumentiertes Verfahren zur Schlüsselrotation, das im Ernstfall in Stunden statt in Tagen durchläuft.

Wer solche Gateways neu einführt, sollte die Standardkonfiguration nie ungeprüft übernehmen. Die Erfahrung aus dem LiteLLM-Umfeld zeigt, dass offene Voreinstellungen über Suchmaschinen für exponierte Dienste sehr schnell gefunden werden. Ein Dienst, der Zugangsdaten für ein Dutzend Anbieter bündelt, verdient dieselbe Sorgfalt wie ein Passwort-Tresor.

Passende Anleitungen auf S-EDV

• LiteLLM CVE-2026-42271: RCE im KI-Gateway und CISA-KEV-Eintrag zeigt, wie eine sehr ähnliche Gateway-Lücke ausgenutzt wurde und was der KEV-Eintrag praktisch bedeutet.
• Exponierte LiteLLM-Gateways mit Standardschlüssel im Internet ordnet ein, wie oft offene Voreinstellungen bei KI-Gateways tatsächlich im Netz stehen.
• LiteLLM als LLM-Gateway mit Docker betreiben beschreibt den abgesicherten Betrieb eines KI-Gateways im Container inklusive Schlüsselverwaltung.

Quellen

• The Hacker News: Critical Bifrost AI Gateway Flaw Lets Attackers Run Commands Without Credentials, 22.09.2026
• NIST NVD: CVE-2026-90898
• JFrog Security Research Blog, Erstveröffentlichung der Schwachstelle
• Bifrost-Projekt auf GitHub (maximhq/bifrost)