Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-09-06T12:17:15.583Z",
  "pubdate": "2026-09-06T12:17:15.583Z",
  "executiveSummary": "Bifrost HTTP transport versions prior to 2.0.0 contain a critical vulnerability allowing unauthenticated remote code execution (RCE) or server-side request forgery (SSRF).\nThe vulnerability stems from the improper handling of custom plugin paths provided via the /api/plugins endpoint when management authentication is disabled.\nBy supplying an HTTP URL as a plugin path, an unauthenticated attacker can force the application to download, store, and execute arbitrary shared object (.so) files.\nThe impact is contingent on the application's build configuration; dynamically linked builds (DYNAMIC=1) facilitate full RCE, executing malicious code with the privileges of the Bifrost process user.\nStatically linked builds are restricted to SSRF due to inherent limitations in Go's plugin loading mechanism.\nExploitation is considered complex, requiring the attacker to provide a malicious plugin payload specifically compiled to match the host's Go version, operating system, architecture, and dynamic linkage requirements.\nThe vulnerability represents a severe security risk for environments using default, unauthenticated Bifrost configurations.",
  "technicalDetails": "The vulnerability resides within the Bifrost HTTP transport plugin loading logic, specifically involving the /api/plugins POST endpoint. When the application's management authentication is disabled (governance.auth_config.is_enabled=false), which serves as the default configuration, the API fails to enforce authorization for plugin management operations.\nThe core issue is a lack of input validation and sanitization during the plugin loading process. The shared-object loader is configured to process path strings prefixed with 'http://' as remote download URLs. When a user submits a POST request to /api/plugins with a plugin path set to an HTTP URL, the application performs an unauthenticated fetch of the remote resource. The response body is written to a temporary file on the local filesystem with a .so extension.\nUpon successful download, the application passes this temporary file path to the Go 'plugin.Open' function. This function attempts to load the shared object into the process's address space. If the environment is built with dynamic linking (DYNAMIC=1), 'plugin.Open' successfully maps the library and invokes the optional 'Init' function. Because the process executes this code, the attacker achieves arbitrary RCE with the system privileges assigned to the Bifrost process. This execution occurs immediately upon the successful loading of the plugin.\nThe attack flow proceeds as follows: 1) The attacker identifies a target instance of Bifrost with authentication disabled. 2) The attacker hosts a malicious Go-compiled shared object that is binary-compatible with the target host's specific architecture, OS, and Go toolchain version. 3) The attacker sends a POST /api/plugins request specifying the URL of the malicious payload. 4) The server downloads the file, saves it, and executes 'plugin.Open'. 5) The malicious 'Init' code executes, granting the attacker control over the host process.\nIn scenarios where Bifrost is deployed using the vendor-provided statically linked Docker images, the 'plugin.Open' call fails with a 'Dynamic loading not supported' error. In these instances, the vulnerability is limited to SSRF, as the application still performs the outbound network request to the attacker-controlled URL, potentially revealing internal network topology or facilitating bypasses of network-level security controls.\nThis vulnerability affects all Bifrost HTTP transport versions through 1.6.11 and any versions prior to 2.0.0. The requirement to match the host environment's specific binary characteristics acts as a technical barrier, elevating the attack complexity for an adversary."
}