CVE-2026-86242 in Bifrost
Summary
by MITRE • 09/06/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/07/2026
The vulnerability in Bifrost HTTP transport versions prior to 2.0.0 represents a critical security flaw rooted in insecure plugin loading mechanisms when management authentication is disabled, which is the default configuration state governed by governance.auth_config.is_enabled=false. The core technical failure occurs during the handling of custom plugins submitted via unauthenticated POST requests to the /api/plugins endpoint. Specifically, the system accepts a plugin path that is an HTTP URL rather than a local file path. This design flaw allows any remote actor with network access to supply arbitrary URLs for dynamic library loading without providing credentials or undergoing authentication checks. The shared-object loader interprets this http-prefixed string as a download target, fetching the content from the specified external server and writing it directly into a temporary .so (shared object) file on the local filesystem. This downloaded binary is then immediately passed to Go's plugin.Open function for initialization.
The operational impact of this flaw varies significantly based on how Bifrost was compiled, creating two distinct attack vectors depending on the build configuration. On dynamically linked builds, indicated by DYNAMIC=1 or the absence of static-link flags, which are required by vendors for custom Go plugins to function correctly, plugin.Open is expected to succeed and execute immediately. In this scenario, the vulnerability results in unauthenticated remote code execution (RCE). The Init function runs with the privileges of the Bifrost process user, granting attackers full control over the application environment. This aligns with CWE-94 Improper Control of Generation of Code or CGI, as well as CWE-20 Improper Input Validation, since the system fails to validate that plugin sources are trusted local files rather than arbitrary remote URLs.
Conversely, on published statically linked Docker images, the behavior differs due to compilation constraints. In these environments, plugin.Open fails with a Dynamic loading not supported error because static binaries cannot load external shared objects at runtime. Consequently, while unauthenticated RCE is prevented in this specific build class, the vulnerability still manifests as server-side request forgery (SSRF). Attackers can force the Bifrost process to make HTTP requests to arbitrary internal or external destinations by supplying malicious URLs in the plugin path field. This SSRF capability allows attackers to probe internal network services, exfiltrate data from metadata endpoints, or pivot into more secure internal networks that are otherwise inaccessible from the public internet.
The attack complexity for achieving remote code execution is classified as high due to strict environmental constraints imposed by Go's dynamic loading requirements. For a malicious plugin to successfully execute on a dynamically linked target, it must be compiled with exact compatibility regarding the host system's Go version, operating system, and CPU architecture. Furthermore, the binary linkage type must match expectations for loadable plugins. This requirement limits the pool of viable targets but does not eliminate the risk, particularly in environments where administrators may customize builds or use specific versions that align with their infrastructure stack. The vulnerability affects all 1.6.x HTTP transport lines through version 1.6.11 and remains unpatched in those releases.
Mitigation strategies must address both the authentication gap and the input validation failure. Administrators should immediately enable management authentication by setting governance.auth_config.is_enabled=true to prevent unauthenticated access to plugin endpoints, thereby neutralizing the SSRF vector entirely regardless of build type. For environments requiring dynamic plugins on dynamically linked builds, it is imperative to restrict plugin sources to trusted local file paths only and implement strict allow-listing for accepted URLs if remote loading remains a business requirement. Upgrading to version 2.0.0 or later resolves this issue by enforcing proper validation and authentication checks before processing plugin requests. Additionally, organizations should audit their deployment configurations to ensure that default settings are not left in insecure states, particularly regarding the governance.auth_config parameter which defaults to disabled for ease of initial setup but poses severe risks in production environments.