CVE-2026-86242: Unauthenticated RCE via Custom Plugin HTTP Path on Dynamically Linked Builds
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 default, governance.authconfig.isenabled=false). The shared-object loader treats an http-prefixed path as a download URL, writes the body to a temporary .so, and passes it to Go's plugin.Open. After a successful open, optional Init runs immediately with the supplied config as the Bifrost process user. On documented dynamically linked builds (DYNAMIC=1 / no static-link flags), which the vendor requires for custom Go plugins, plugin.Open is expected to succeed and this is unauthenticated remote code execution. On the published statically linked Docker image, plugin.Open fails with Dynamic loading not supported, so that build class is only server-side request forgery. Attack complexity is High because the attacker cannot force RCE on the default static image and a loadable plugin must match the host Go version, OS, architecture, and linkage. The 1.6.x HTTP transport line through 1.6.11 does not contain the fix.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Bifrost HTTP transportto a version that resolves this vulnerability.Fixed in 2.0.0Patch PR #5763
Event History
Frequently Asked Questions
Which deployments can be remotely code executed through this issue?
Remote code execution is expected on dynamically linked builds that support custom Go plugins, with management authentication disabled and an attacker able to submit a compatible plugin. The vendor documents these builds as DYNAMIC=1 or builds without static-link flags.
Are deployments using the published Docker image exposed to remote code execution?
The published statically linked Docker image is not expected to load the downloaded shared object because plugin.Open fails with “Dynamic loading not supported.” That build class remains exposed to server-side request forgery through the HTTP plugin path.
What must an attacker provide for code execution to succeed?
They need a loadable Go plugin matching the target host's Go version, operating system, architecture, and linkage. This compatibility requirement is why exploitation has high attack complexity.
How can I quickly assess whether an instance is exposed?
Check whether the HTTP transport version is before 2.0.0, whether governance.auth_config.is_enabled is false, and whether the build is dynamically linked. The 1.6.x HTTP transport line through 1.6.11 does not contain the fix.
What can be changed if updating is not immediately possible?
Enable management authentication so POST /api/plugins is not unauthenticated. Also identify and avoid dynamically linked deployments that permit custom Go plugin loading until a fixed version can be used.