Bifrost HTTP transport versions prior to 2.0.0 allow an unauthenticated attacker to create a custom plugin whose path is an HTTP URL through the POST /api/plugins endpoint when dashboard authentication is disabled. The shared‑object loader treats the HTTP prefix as a download URL, writes the retrieved content to a temporary .so file, and passes it to Go's plugin.Open. Once the plugin is opened, its optional Init function runs immediately with the supplied configuration as the Bifrost process user, providing a full uncompromised remote code execution channel. The flaw is rooted in improper access control (CWE‑284), missing authentication checks (CWE‑306), and insecure code execution (CWE‑94).

The vulnerability affects the Bifrost project maintained by maximhq. All HTTP transport builds before version 2.0.0, including the 1.6.x series through 1.6.11, are susceptible when the product is built with dynamic linking enabled. The vendor requires dynamic linking for custom Go plugins, but the published statically linked Docker image is not affected because plugin.Open fails in that configuration, limiting the impact to server‑side request forgery in that scenario.

The assessed CVSS score is 8.1, indicating a high severity. No EPSS data is available, and the vulnerability is not listed in CISA’s KEV catalog. Attackers can exploit the flaw over an open network path, as the default configuration turns off management authentication. Successful exploitation requires delivering a compatible Go plugin that matches the host's Go version, operating system, architecture, and linking style, which makes the attack complexity high. Once succeeded, the attacker gains full control of the Bifrost process with the privileges it runs under.