Schwachstelle in Bifrost ermöglicht Befehlsausführung ohne Authentifizierung über MCP-Registrierung

Im offenen AI-Gateway Bifrost, das Anfragen an mehr als 20 Anbieter großer Sprachmodelle weiterleitet, wurden zwei Schwachstellen entdeckt, die einem nicht authentifizierten Angreifer die Ausführung beliebiger Befehle auf dem Server ermöglichen. Die gefährlichste davon — CVE-2026-90898 — lässt sich in der Standardkonfiguration mit nur einer HTTP-Anfrage an die Management-API ausnutzen. Nach Angaben von JFrog Security Research liegt der CVSS-Score bei 9.8. Der Patch ist in Version transports/v2.1.0 verfügbar. Betreibern, die Bifrost mit deaktivierter Authentifizierung der Management-API (Standardeinstellung) einsetzen, wird dringend geraten, umgehend zu aktualisieren oder Workarounds anzuwenden.

Technische Details der Schwachstellen

CVE-2026-90898: Befehlsausführung über Registrierung eines MCP-Clients

Der Forscher Yuval Moravchik von JFrog stellte fest, dass ein Angreifer bei deaktivierter Authentifizierung der Management-API (der Parameter governance.auth_config.is_enabled ist standardmäßig auf false gesetzt) eine einzige POST-Anfrage an den Endpoint /api/mcp/client senden und einen MCP-Client des Typs stdio registrieren kann. Bifrost startet den im Request angegebenen Befehl sofort im Namen des Gateway-Prozesses – noch bevor der MCP-Handshake abgeschlossen ist. Im offiziellen Docker-Image wird der Prozess unter dem Benutzer appuser ausgeführt.

Betroffen sind alle Versionen von Bifrost HTTP transport bis 2.1.0, einschließlich Version 2.0.0 und der 1.6.x-Reihe bis einschließlich 1.6.11. Da das Gateway die API-Keys der angebundenen Provider speichert, kann die Befehlsausführung im Kontext des Gateway-Prozesses einem Angreifer potenziell Zugriff auf diese Zugangsdaten verschaffen.

CVE-2026-86242: Laden eines bösartigen Plugins über HTTP

Die zweite Schwachstelle, CVE-2026-86242, wurde am 6. September von JFrog offengelegt. Nach Angaben der Forscher liegt der CVSS-Score bei 8.1. Ein nicht authentifizierter Angreifer kann ein benutzerdefiniertes Plugin registrieren, indem er eine HTTP-Adresse als Pfad angibt. Bifrost lädt die Datei herunter, speichert sie als temporäres Shared Object und lädt sie über die Go-Funktion plugin.Open.

Die Auswirkungen hängen vom Build-Typ ab: Bei dynamisch gelinkten Builds (erforderlich für benutzerdefinierte Go-Plugins) wird der geladene Code im Kontext des Gateway-Prozesses ausgeführt. Bei statisch gelinkten Builds, einschließlich des offiziellen Docker-Images, schlägt plugin.Open mit einem Fehler fehl, und die Schwachstelle reduziert sich auf eine SSRF. Der Patch ist ab transports/v2.0.0 verfügbar.

Unterschiede bei der Patch-Priorisierung

Die beiden Schwachstellen erfordern unterschiedliche Update-Strategien. CVE-2026-90898 wird nur in Version transports/v2.1.0 behoben – die Zwischenversion 2.0.0 bleibt weiterhin verwundbar. CVE-2026-86242 ist bereits in transports/v2.0.0 behoben. Für typische Deployments auf Basis des offiziellen Docker-Images (statische Verlinkung) stellt jedoch insbesondere CVE-2026-90898 die größte Bedrohung dar: Der Pfad zur Ausführung beliebiger Befehle funktioniert auf diesem Image ohne zusätzliche Voraussetzungen. Der Pfad zur Remote Code Execution über CVE-2026-86242 wird auf demselben Image blockiert und reduziert sich lediglich auf SSRF. Ein Update auf transports/v2.1.0 schließt somit beide Schwachstellen und sollte vorrangig erfolgen.

Netzwerk-Exposition: Binärdatei und Docker

Das Maß der Erreichbarkeit der Management-API hängt von der Art des Deployments ab. Die Standard-Binärdatei von Bifrost bindet die Management-API an localhost und beschränkt den Zugriff damit auf die lokale Maschine. Das offizielle Docker-Image bindet sie an 0.0.0.0 – ist der Port veröffentlicht, wird die API außerhalb des Containers erreichbar. Dieser Unterschied ist bei der Bewertung des tatsächlichen Risikos entscheidend: Container-Deployments mit veröffentlichtem Management-Port sind ohne weitere Voraussetzungen für eine Remote-Ausnutzung anfällig.

Kontext: dritte Schwachstelle innerhalb eines Monats

Beide Schwachstellen haben dieselbe Hauptursache gemeinsam – die Management-API von Bifrost wird standardmäßig ohne Authentifizierung ausgeliefert. Es handelt sich bereits um das zweite und dritte Sicherheitsproblem, das innerhalb von weniger als einem Monat im Projekt offengelegt wurde: Zuvor, Ende August, wurde eine nicht damit in Zusammenhang stehende SSRF-Schwachstelle CVE-2026-55245 behoben (Details dazu sind nur aus dem ursprünglichen Nachrichtenmaterial bestätigt; ein primärer Sicherheitshinweis liegt nicht vor).

Zum Zeitpunkt der Veröffentlichung ist keine der Bifrost-Schwachstellen im CISA KEV-Katalog aufgeführt, und es wurden keine unabhängigen Hinweise auf eine aktive Ausnutzung gefunden. Es existieren jedoch öffentliche Proof-of-Concepts, und eine ähnliche Command-Injection-Schwachstelle in einem anderen AI-Gateway, LiteLLM, wurde laut dem Ausgangsmaterial im Juni 2026 nach bestätigter Ausnutzung in den CISA KEV-Katalog aufgenommen.

Empfehlungen

• Aktualisieren Sie Bifrost HTTP transport auf Version transports/v2.1.0 – damit werden beide Schwachstellen geschlossen. Version 2.0.0 behebt nur CVE-2026-86242.
• Wenn ein sofortiges Update nicht möglich ist, aktivieren Sie die Authentifizierung der Management-API: Setzen Sie governance.auth_config.is_enabled auf true und vergeben Sie starke Zugangsdaten.
• Beschränken Sie den Netzwerkzugriff auf die Management-API: Veröffentlichen Sie den Management-Port nicht in nicht vertrauenswürdigen Netzen, insbesondere nicht in Docker-Deployments.
• JFrog empfiehlt, jede Instanz, die mit deaktivierter Authentifizierung und von außen erreichbarer Management-API betrieben wurde, als kompromittiert zu betrachten. In solchen Fällen ist es notwendig, die virtuellen Schlüssel und API-Keys der Provider zu rotieren.
• Die 1.6.x-Reihe bis einschließlich 1.6.11 enthält keine der Korrekturen – eine Migration auf 2.1.0 ist obligatorisch.

Beide Bifrost-Schwachstellen sind die Folge der architektonischen Entscheidung, die Management-API standardmäßig ohne Authentifizierung auszuliefern. Für Betreiber, die Bifrost in Container-Umgebungen mit veröffentlichtem Management-Port einsetzen, ist die einzige verlässliche Maßnahme ein Update auf transports/v2.1.0 in Verbindung mit einer gleichzeitigen Rotation aller Provider-Schlüssel, sofern die Instanz von außen erreichbar gewesen sein könnte.