Kurzfassung

Bifrost ist von der kritischen Schwachstelle CVE-2026-90898 betroffen. Der CVSS-Basiswert liegt bei 9.8 und beschreibt eine technisch sehr schwere Lücke, über die sich unter bestimmten Voraussetzungen ohne Anmeldung aus dem Netzwerk Code ausführen lässt. Für Unternehmen ist das vor allem dann dringend, wenn die Management-API erreichbar ist und noch die anfällige Komponente transports v2.0.0 eingesetzt wird.

Was ist passiert?

Die Schwachstelle betrifft die Registrierung von MCP-Clients über die Management-API von Bifrost. Ein als stdio definierter Client besteht aus einem Programm samt Argumenten. Wird ein solcher Client hinzugefügt, startet Bifrost dieses Programm unmittelbar auf dem Gateway.

Entscheidend ist dabei: Für diesen Ablauf ist laut den bekannten technischen Angaben kein MCP-Handshake erforderlich. Wenn die Authentifizierung in der Standardkonfiguration deaktiviert ist, wird jeder Aufrufer wie ein lokaler Administrator behandelt. Dann genügt ein einzelner nicht authentifizierter POST-Aufruf auf /api/mcp/client, um ein Programm mit den Rechten des Bifrost-Prozesses auszuführen.

Technische Details

CVE-2026-90898 hat einen CVSS-Wert von 9.8 (kritisch) mit dem Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Das bedeutet: Angriffe sind über das Netzwerk möglich, die Angriffskomplexität ist gering, es sind keine Berechtigungen und keine Nutzerinteraktion nötig; bei erfolgreicher Ausnutzung drohen hohe Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Der Wert beschreibt die technische Schwere der Schwachstelle, nicht automatisch die tatsächliche Ausnutzung in realen Umgebungen.

Die bekannte Ursache liegt in der Management-API von Bifrost in Verbindung mit der Registrierung eines stdio-Clients. Dieser stdio-Client wird als auszuführender Befehl mit Argumenten interpretiert und unmittelbar gestartet. Auf dem offiziellen Image läuft der Prozess dabei als appuser.

Zur Einordnung der betroffenen Komponente ist wichtig: transports/v2.1.0 verweigert eine nicht authentifizierte stdio-Registrierung mit HTTP 403. transports/v2.0.0 lässt diesen Ablauf dagegen weiterhin zu.

Wer ist betroffen?

Betroffen sind Bifrost-Installationen, bei denen die Management-API erreichbar ist und in denen die Authentifizierung deaktiviert ist. Besonders kritisch ist das in internen Netzen mit vielen administrativen Zugriffspfaden, in Testumgebungen, in Container-Setups mit zu weit geöffneten Ports oder wenn die API versehentlich nach außen exponiert wurde.

Direkt genannt ist die Verhaltensänderung zwischen transports/v2.0.0 und transports/v2.1.0. Jenseits dieser Angabe liegen keine belastbaren Versionsgrenzen für das gesamte Produkt vor. Ob weitere Bifrost-Versionen oder abweichende Deployments betroffen sind, ist derzeit nicht näher eingegrenzt.

Für die meisten Leser ist die Lücke nur dann relevant, wenn Bifrost tatsächlich im Einsatz ist. Wo das Produkt produktiv oder in Entwicklerplattformen verwendet wird, ist die Schwachstelle hingegen hochprioritär.

Empfohlene Maßnahmen

Erstens: Prüfen Sie sofort, ob Bifrost in Ihrer Umgebung läuft und ob die Management-API von anderen Systemen erreichbar ist. Systeme mit exponierter API sollten Sie priorisiert behandeln.

Zweitens: Verifizieren Sie die Authentifizierungseinstellung. Wenn governance.auth_config.is_enabled=false gesetzt ist, sollten Sie die Authentifizierung umgehend aktivieren und ungeschützte Zugriffe auf die API unterbinden.

Drittens: Prüfen Sie, ob noch transports/v2.0.0 eingesetzt wird. Wenn möglich, stellen Sie mindestens auf transports/v2.1.0 um, da diese Version eine nicht authentifizierte stdio-Registrierung mit 403 ablehnt.

Viertens: Begrenzen Sie den Netzwerkzugriff auf die Management-API strikt per Firewall, Security Group, Ingress-Regeln oder Reverse Proxy. Die Schnittstelle sollte nur von administrativen Hosts oder dedizierten Management-Netzen erreichbar sein.

Fünftens: Suchen Sie in Protokollen und Audit-Daten nach verdächtigen POST-Anfragen an /api/mcp/client, insbesondere nach unerwarteten Client-Registrierungen oder nach gestarteten Prozessen, die nicht zu Ihrem regulären Betrieb gehören.

Sechstens: Überprüfen Sie Container- und Host-Telemetrie auf neu gestartete Prozesse unter dem Bifrost-Kontext beziehungsweise unter appuser. Wo Verdacht besteht, sollten Sie Zugangsdaten rotieren, betroffene Instanzen neu aufsetzen und Seitwärtsbewegungen ausschließen.

Ob ein Hersteller-Patch jenseits der genannten Verhaltensänderung in transports/v2.1.0 bereitsteht, ist nicht mitgeteilt.

Einschätzung von CyberSecurity-News.de

Die technische Tragweite ist klar: Wenn eine Management-API ohne Authentifizierung Befehle starten kann, handelt es sich um eine klassische Hochrisiko-Konstellation. Der CVSS-Wert ist hier nachvollziehbar hoch, weil weder Anmeldung noch Nutzerinteraktion erforderlich sind.

Die Informationslage hat aber Grenzen. Bekannt ist die problematische Standardeinstellung mit deaktivierter Authentifizierung und der Unterschied zwischen transports/v2.0.0 und v2.1.0. Weniger klar bleibt, wie breit die verwundbare Basis in realen Installationen ist und ob es außerhalb dieser Komponente weitere Absicherungen gibt. Für Admins heißt das: nicht auf Detailklarheit warten, sondern Erreichbarkeit und Konfiguration sofort selbst prüfen.

Für den DACH-Markt ist das vor allem ein Betriebs- und Härtungsthema. Solche Schwachstellen werden oft nicht durch hochkomplexe Exploits ausgenutzt, sondern durch offen erreichbare Verwaltungsoberflächen und schwache Standardkonfigurationen.

Fazit

Wenn Sie Bifrost einsetzen, sollten Sie die Management-API sofort als potenziellen Einstiegspunkt behandeln. Aktivieren Sie die Authentifizierung, schränken Sie die Erreichbarkeit ein und ersetzen Sie transports/v2.0.0 so schnell wie möglich. Ohne diese Schritte bleibt das Risiko einer direkten Codeausführung zu hoch.

Quellenangabe

Weiterführende technische Informationen bietet der NVD-Eintrag zu CVE-2026-90898.