CVE-2026-90898: Bifrost unauthenticated remote code execution via MCP stdio client registration
Bifrost registers MCP clients through its management API. A stdio client is a command plus args. Bifrost starts that program in the gateway the moment the client is added. No MCP handshake required.
The default is governance.authconfig.isenabled=false. Auth off means every caller is a local admin. One unauthenticated POST /api/mcp/client is enough to run a program as the Bifrost process user (appuser on the official image).
transports/v2.1.0 refuses an unauthenticated stdio registration with 403. transports/v2.0.0 still allows it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Bifrost HTTP transportto a version that resolves this vulnerability.Fixed in 2.1.0 - Compensating control
Ensure the MCP stdio client registration endpoint requires authenticated requests (dashboard authentication enabled) by setting governance.auth_config.is_enabled=true, since the default is governance.auth_config.is_enabled=false and unauthenticated registration is possible when disabled or unconfigured.
Event History
Frequently Asked Questions
Which deployments are exposed to unauthenticated exploitation?
Deployments using transports/v2.0.0 with governance.auth_config.is_enabled=false are exposed. This is the default configuration, where every caller is treated as a local administrator.
What does an attacker need to exploit the issue?
An attacker only needs network access to send one unauthenticated POST request to /api/mcp/client. No MCP handshake, credentials, or user interaction is required.
What privileges does successful exploitation provide?
The registered stdio client command is started by the gateway immediately. It runs as the Bifrost process user, which is appuser in the official image.
What should be done if an immediate upgrade is not possible?
Enable governance.auth_config.is_enabled to prevent unauthenticated callers from being treated as administrators. Restrict access to the management API so untrusted callers cannot submit MCP client registrations.
How can I determine whether a deployment has the fix?
transports/v2.1.0 rejects unauthenticated stdio client registrations with HTTP 403. transports/v2.0.0 still permits those registrations.