Das Ausmaß der Angriffsfläche hängt von der Betriebsart ab. Die reguläre Bifrost-Binärdatei bindet die Management-API standardmäßig an localhost, womit der Zugriff auf die lokale Maschine beschränkt bleibt. Das offizielle Docker-Image hingegen lauscht auf 0.0.0.0 – wird der Port veröffentlicht, ist die Management-Schnittstelle von außerhalb des Containers erreichbar. Als Prozessbenutzer läuft im Docker-Image appuser.
Die korrigierte Fassung transports/v2.1.0 beantwortet den Registrierungsversuch eines stdio-MCP-Clients durch einen nicht authentifizierten Aufrufer mit dem Statuscode 403. Wer nicht sofort aktualisieren kann, sollte laut JFrog governance.auth_config.is_enabled auf true setzen, starke Zugangsdaten vergeben und den Management-Listener von nicht vertrauenswürdigen Netzen fernhalten. Zusätzlich raten die Forscher dazu, virtuelle Schlüssel und die API-Schlüssel der Anbieter zu rotieren.
Wichtig für die Versionspflege: Wer transports/v2.0.0 einsetzt, ist von der MCP-Lücke weiterhin betroffen. Diese Ausgabe behob lediglich eine frühere Plugin-Schwachstelle, unterbindet die unauthentifizierte Registrierung aber nicht. Die 1.6.x-Reihe bis einschließlich 1.6.11 enthält keinen der beiden Fixes.
Jene frühere Plugin-Lücke geht auf Or Peles aus demselben Forschungsteam zurück und wurde am 6. September offengelegt. CVE-2026-86242 (CVSS 8.1) erlaubt es einem nicht authentifizierten Angreifer, ein eigenes Plugin zu registrieren, dessen Pfad eine HTTP-URL ist. Bifrost lädt die Datei herunter, schreibt sie als temporäres Shared Object und bindet sie über die Go-Funktion plugin.Open ein.
Bei dynamisch gelinkten Builds – die Bifrost für eigene Go-Plugins voraussetzt – wird das Plugin geladen und sein Code im Kontext des Gateway-Prozessbenutzers ausgeführt. Bei statisch gelinkten Builds, zu denen auch das offizielle Docker-Image zählt, scheitert plugin.Open; übrig bleibt dann eine Server-Side Request Forgery. Behoben ist dieses Problem in transports/v2.0.0.
Beide Schwachstellen teilen dieselbe Ursache: Die Management-API von Bifrost wird mit standardmäßig abgeschalteter Authentifizierung ausgeliefert. Es handelt sich um das zweite und dritte Sicherheitsproblem, das innerhalb von weniger als einem Monat in dem Projekt öffentlich wurde – zuvor war eine nicht damit zusammenhängende SSRF-Lücke (CVE-2026-55245) behoben worden.
Die MCP-Schwachstelle reiht sich in ein Muster ein, das bereits zu Angriffen in freier Wildbahn geführt hat. Im April 2026 legten Forscher einen Konstruktionsfehler im STDIO-Transport von MCP offen, der die offiziellen SDKs von Anthropic betrifft. Eine vergleichbare Befehlsinjektion im KI-Gateway LiteLLM wurde aktiv ausgenutzt und im Juni in den Known-Exploited-Vulnerabilities-Katalog der CISA aufgenommen. Zum Zeitpunkt der Veröffentlichung ist keine der beiden Bifrost-CVEs im KEV-Katalog gelistet.