CVE-2026-90898 (CVSS score: 9.8) allows an unauthenticated attacker to run arbitrary commands on a Bifrost gateway server with a single HTTP request.
CVE-2026-90898: unauthenticated MCP stdio registration can spawn commands
Yuval Moravchick of JFrog Security Research discovered a defect in Bifrost's HTTP transport that lets an attacker register a stdio-type MCP client via a single unauthenticated POST to the management API endpoint /api/mcp/client. According to the report, Bifrost immediately starts the specified command — before any MCP handshake — and runs it as the gateway process user.
Because the gateway stores API keys for every connected provider, executing commands in the gateway process context effectively grants access to those credentials. On the official Docker image the gateway process runs as the user appuser; the stock Bifrost binary, by contrast, binds the management API to localhost by default, which limits exposure unless the container's management port is published.
CVE-2026-86242: plugin-by-URL leads to remote code or SSRF depending on build
A second, related issue disclosed by Or Peles of the same research team is tracked as CVE-2026-86242 (CVSS score: 8.1). In this case an unauthenticated attacker can register a custom plugin whose path is an HTTP URL. Bifrost downloads the file, writes it as a temporary shared object, and attempts to load it using Go's plugin.Open function.
On dynamically linked builds — which Bifrost requires for custom Go plugins — that sequence results in the plugin loading and its code running as the gateway process user. On statically linked builds, including the official Docker image, plugin.Open fails and the observable effect is server-side request forgery only. The fix for this plugin flaw is included in transports/v2.0.0.

This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildRoot cause: management API authentication disabled by default
Both flaws share the same root cause: the Bifrost management API ships with authentication disabled by default. That default configuration is central to how the MCP stdio registration can be done without credentials and how remote plugin registration can be triggered from an unauthenticated caller.
These two disclosures are the second and third security issues revealed in the project in under a month; an unrelated SSRF flaw (CVE-2026-55245) was fixed in late August. The MCP flaw also follows a pattern researchers have warned about: in April 2026 a design flaw in MCP's STDIO transport affecting Anthropic's official SDKs was disclosed, and a similar command-injection bug in LiteLLM was actively exploited and added to CISA's Known Exploited Vulnerabilities catalog in June. Neither Bifrost CVE appears in the KEV catalog as of publication.
Available fixes and recommended mitigations for operators
- Upgrade: operators should upgrade to transports/v2.1.0, which returns 403 when an unauthenticated caller tries to register a stdio MCP client.
- Interim hardening: for those who cannot upgrade immediately, set governance.auth_config.is_enabled to true, use strong credentials, and keep the management listener off untrusted networks.
- Triage and recovery: JFrog advises treating any instance that ran with authentication disabled and the management API exposed as compromised. The vendor recommends rotating virtual keys and provider API keys for any affected instance.
- Version notes: transports/v2.0.0 remains affected by the MCP registration flaw (it fixed only the earlier plugin vulnerability). The 1.6.x line through 1.6.11 contains neither fix.
What this means for operators, Docker deployments, and provider API owners
Operators: If a gateway has been run with governance.auth_config.is_enabled set to false and its management API reachable, JFrog's guidance is to assume compromise and rotate keys. Applying transports/v2.1.0 is the clear corrective step for the MCP issue.
Docker deployments: the official Docker image binds the management API to 0.0.0.0 by default, which makes the management listener reachable from outside the container if the port is published. That contrasts with the stock binary's localhost binding and increases exposure unless operators explicitly keep the port private or enable authentication.
Provider API owners: because Bifrost stores API keys for each connected LLM provider, an attacker who runs commands as the gateway process could access those credentials; rotating virtual keys and provider API keys is the remediation JFrog recommends for instances that may have been exposed.
The technical record in the disclosure is clear: the immediate fixes are available, mitigations are straightforward, and the most consequential misconfiguration is deliberate or accidental disabling of management API authentication. For any team running Bifrost, the decision now is binary — enable authentication and contain the management listener, or upgrade transports to the patched releases and rotate credentials if the older configuration was exposed. How quickly that choice is acted on will determine whether these high-severity flaws remain a research finding or become an operational incident.




