Unauthenticated MCP client registration runs arbitrary commands on the Bifrost LLM gateway (CVE-2026-90898)
VulnCheck's canary sensors recorded exploitation attempts against this endpoint on 2026-10-23, so any internet-reachable Bifrost gateway still running with the default auth-off configuration can be turned into a command-execution foothold by whoever finds it next.
Bifrost's management API lets a caller register a stdio MCP client — a command plus arguments — and the gateway executes that program the moment the client is added, with no MCP handshake required. Because the default is governance.auth_config.is_enabled=false, every caller is treated as a local admin, so a single unauthenticated POST to /api/mcp/client runs an attacker-chosen program as the Bifrost process user (appuser on the official image); the same handler also accepted unauthenticated http/sse clients pointed at loopback or private addresses, enabling SSRF against internal services including the 169.254.169.254 cloud metadata endpoint.
Affected: maximhq Bifrost transports < v2.1.0 (transports/v2.0.0 and earlier)
How to Test
Confirm which Bifrost transports release you run; anything before transports/v2.1.0 is affected. Check your configuration for governance.auth_config.is_enabled — if it is false (the default), the management API accepts unauthenticated callers as admins. Review reverse-proxy or management API access logs for POST /api/mcp/client requests from unexpected sources, particularly bodies with connection_type "stdio" or a connection_string resolving to loopback, RFC1918 or 169.254.169.254 addresses. List the currently registered MCP clients and compare them against what you provisioned in config.json; any stdio client you did not add is a compromise indicator, as are unexpected child processes under the Bifrost process user (appuser on the official image).
How to Patch
Upgrade to transports/v2.1.0, which carries fix commit 12e170352bd25eab1ae9ba16611f1797d1fd8fdc and refuses unauthenticated stdio MCP client registration and unauthenticated http/sse clients targeting loopback, private, link-local or unspecified addresses with HTTP 403 while leaving authenticated admins full access. If you cannot upgrade immediately, set governance.auth_config.is_enabled=true so the management API requires a genuine credential, restrict network access to /api/mcp/client to trusted operators, and provision any stdio MCP clients you need through config.json rather than the API.