Critical Bifrost AI Gateway Flaw Lets Attackers Run Commands Without Credentials

Bifrost, an enterprise AI gateway for routing requests to model providers, contains a high-severity server-side request forgery flaw (CWE-918, CVSS 4.0 8.7) in the isPublicIP function in core/providers/utils/fetch.go, which misclassifies Carrier-Grade NAT (100.64.0.0/10), IPv6 6to4 (2002::/16), NAT64 (64:ff9b::/96 and 64:ff9b:1::/48), and deprecated IPv6 site-local (fec0::/10) addresses as public. The flaw is reached through FetchAndEncodeURL when Bifrost handles image or document URLs for the Bedrock and Vertex providers, so a remote attacker who controls the URL supplied in a multimodal request can direct the gateway to fetch an attacker-chosen address while bypassing private-IP checks. Because these special-use ranges are treated as public, the attacker can make the gateway request internal services that would otherwise be blocked, including cloud instance metadata endpoints reached via 6to4 or NAT64 encodings. Deployments running Bifrost prior to 1.5.17 that use Bedrock or Vertex multimodal URL fetching are affected. There is no public proof of concept, the issue is not in CISA KEV, and EPSS estimates a 0.4% probability of exploitation within 30 days, so exploitation is not currently known to be occurring; the fix is in version 1.5.17.

Do: Upgrade Bifrost to version 1.5.17 or later. As an interim measure, restrict or disable user-supplied image/document URLs for Bedrock and Vertex requests, and validate or block URLs resolving to special-use ranges (100.64.0.0/10, 2002::/16, 64:ff9b::/96, 64:ff9b:1::/48, fec0::/10). Review gateway logs for requests to internal or cloud metadata endpoints (for example, 169.254.169.254 reached via 6to4 or NAT64 encodings) to check for prior probing.

Bifrost's HTTP management transport before 2.0.0 accepts an enabled custom plugin whose path is an HTTP URL through the unauthenticated POST /api/plugins endpoint whenever management authentication is disabled (governance.auth_config.is_enabled=false, the default); the shared-object loader downloads the URL body to a temporary .so and passes it to Go's plugin.Open, whose optional Init function then runs immediately as the Bifrost process user with attacker-supplied config. On dynamically linked builds (DYNAMIC=1, which the vendor requires for custom Go plugins) this is unauthenticated remote code execution, while on the published statically linked Docker image plugin.Open fails with 'Dynamic loading not supported' and the flaw degrades to server-side request forgery. Exploitation for full RCE is rated high attack complexity because the attacker cannot force code execution on the default static image and a loadable plugin must match the host's Go version, OS, architecture and linkage. All releases before 2.0.0 are affected, and the 1.6.x HTTP transport line through 1.6.11 does not contain the fix. No public proof-of-concept, CISA KEV listing, or confirmed exploitation is known; EPSS currently estimates a 0.6% probability of exploitation within 30 days.

Do: Upgrade the Bifrost HTTP transport to 2.0.0 or later, noting that the 1.6.x line including 1.6.11 has no backported fix; as interim mitigation, enable management authentication (governance.auth_config.is_enabled=true) or restrict network access to POST /api/plugins. Check your deployment's linkage: dynamically linked builds (DYNAMIC=1, required for custom Go plugins) are exposed to unauthenticated RCE, while the published statically linked Docker image is limited to SSRF.

Bifrost, an open-source MCP gateway, exposes a management API for registering MCP clients, and a stdio client registration is simply a command plus arguments that the gateway executes immediately upon addition, with no MCP handshake required. Because the default configuration ships with governance.auth_config.is_enabled=false, every caller of the management API is treated as a local admin, so a single unauthenticated POST to /api/mcp/client lets an attacker run an arbitrary program as the Bifrost process user (appuser in the official container image), giving full system compromise with CVSS 9.8. Any deployment running the vulnerable transports plugin with the management API network-reachable and default auth disabled is affected. The transports plugin v2.1.0 mitigates this by returning 403 for unauthenticated stdio registrations, but transports v2.0.0 still allows it. No public proof of concept and no in-the-wild exploitation are known at this time.

Do: Upgrade the transports plugin to v2.1.0 or later, which rejects unauthenticated stdio client registrations with a 403. Independently, enable governance authentication by setting governance.auth_config.is_enabled=true and restrict network access to the management API (/api/mcp/client and related endpoints) to trusted networks only. Audit gateway logs for unexpected MCP client registrations or spawned child processes running as the appuser account.