Bifrost HTTP Transport EUVD-2026-72104

For SSRF on all builds: Management authentication must be disabled, which is the default state (governance.auth_config.is_enabled=false); no other special configuration is required and the management API must be network-reachable. For full RCE: Additionally, Bifrost must be running as a dynamically linked build compiled with DYNAMIC=1 or equivalent non-static flags - this is NOT the default published Docker image. The attacker-supplied .so must exactly match the target's Go toolchain version, operating system, and CPU architecture, as Go's plugin ABI is not stable across versions. Factors limiting exploitation: (1) the official statically linked Docker image blocks plugin.Open() entirely, confining impact to SSRF; (2) the Go plugin ABI requirement means a generic payload will not execute on mismatched host environments; (3) RCE execution is immediate upon plugin.Open() success with no further user interaction required once the endpoint is reached. Enabling governance.auth_config.is_enabled=true eliminates unauthenticated access to the endpoint for all build types.

The CVSS 8.1 score (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) reflects a two-tier threat model: the default statically linked Docker image is limited to SSRF, while dynamically linked operator deployments face full unauthenticated RCE with C:H/I:H/A:H impact. The AC:H designation is warranted because an attacker cannot force the RCE outcome on static builds and must craft a .so that exactly matches the target's Go toolchain version, OS, and CPU architecture - even a mid-sized municipal IT operator in leszno running a custom dynamic build would face this non-trivial exploitation hurdle. The most universally dangerous condition is the default-off management authentication (governance.auth_config.is_enabled=false), which makes every pre-2.0.0 Bifrost instance reachable on its management API susceptible to SSRF without any preconditions. No EPSS data was provided in the input and the vulnerability is absent from CISA KEV, suggesting no confirmed widespread active exploitation; however, JFrog's targeted discovery implies a research-grade, proof-of-concept-capable finding. Operators running DYNAMIC=1 or non-Docker Bifrost deployments should treat this as the higher-priority RCE path; all other operators should prioritize the SSRF risk from the universally exploitable default configuration.

An attacker with network access to the Bifrost management API (no credentials required in the default configuration) sends a crafted POST /api/plugins request with a plugin path pointing to an HTTP URL hosting a Go shared-object compiled to match the target's exact Go version, OS, and architecture. On a dynamically linked Bifrost deployment, the server fetches the .so, loads it via plugin.Open(), and immediately executes Init() as the Bifrost process user, achieving full remote code execution with no user interaction. On the default static Docker image, the .so load fails but the HTTP fetch proceeds, enabling SSRF to enumerate internal network services or exfiltrate metadata from cloud instance endpoints.