CVE-2026-86242
HighCVSS 8.1Summary
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.
Risk Assessment
Remote code execution or SSRF may lead to full system compromise or access to internal resources, depending on the build.
Recommendation
Upgrade Bifrost to version 2.0.0 or later, which includes the fix. If not possible, enable management authentication and restrict API access.
Other vulnerabilities in Bifrost
See all- CVE-2026-86840Unknown
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.
- CVE-2026-55245High
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.
Original NVD description (English source)
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.auth_config.is_enabled=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.