Bifrost vulnerabilities

Bifrost registers MCP clients through its management API, where a stdio client is a command plus args that is started immediately upon client addition, with no MCP handshake required. Authentication is disabled by default (governance.auth_config.is_enabled=false), meaning every caller is treated as a local admin. A single unauthenticated POST /api/mcp/client is enough to run a program as the Bifrost process user (appuser on the official image).

The `vtoken-minting` and `slpx` pallets in Bifrost contain an improper authorization vulnerability in channel commission attribution. A signed account can supply an arbitrary registered `channel_id` when minting tokens without verifying that the caller is authorized to mint on behalf of that channel. This allows an attacker to inflate a channel's recorded mint volume and cause protocol commission payments to be disproportionately distributed to that channel during commission settlement.

Bifrost HTTP transport before 2.0.0 accepts an enabled custom plugin whose path is an HTTP URL through unauthenticated POST /api/plugins when management authentication is disabled. The shared-object loader treats an http-prefixed path as a download URL, writes the body to a temporary .so, and passes it to plugin.Open. On dynamically linked builds this is unauthenticated remote code execution; on the static Docker image it is only SSRF.

Bifrost before version 1.5.17 incorrectly classifies addresses from CGNAT, 6to4, NAT64, and fec0::/10 ranges as public. An attacker controlling a multimodal request URL can make the gateway fetch internal services, including cloud instance metadata.