CVE-2026-86242

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.

What to 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.