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.
Metrics
Affected Vendors & Products
References
History
Tue, 08 Sep 2026 19:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Sun, 06 Sep 2026 13:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Maximhq
Maximhq bifrost |
|
| Vendors & Products |
Maximhq
Maximhq bifrost |
Sun, 06 Sep 2026 11:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| 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. | |
| Title | Unauthenticated RCE via Custom Plugin HTTP Path on Dynamically Linked Builds | |
| Weaknesses | CWE-284 CWE-306 CWE-94 |
|
| References |
|
|
| Metrics |
cvssV3_1
|
Status: PUBLISHED
Assigner: JFROG
Published: 2026-09-06T11:20:11.759Z
Updated: 2026-09-08T18:23:28.573Z
Reserved: 2026-09-06T09:15:54.440Z
Link: CVE-2026-86242
Updated: 2026-09-08T18:23:25.435Z
Status : Awaiting Analysis
Published: 2026-09-06T12:17:15.583
Modified: 2026-09-09T15:44:01.133
Link: CVE-2026-86242
No data.