CVE-2026-90898: Bifrost AI Gateway Flaw Allows Command Execution

CVE-2026-90898 (CVSS 9.8), disclosed on 22 September 2026 by JFrog Security Research, turns a single anonymous HTTP request into command execution on the server hosting the gateway. No credentials are needed, and no protocol handshake is required. No human interaction is required either.

Bifrost is an open source AI gateway that routes traffic to more than twenty LLM providers. The flaw affects every version of the HTTP transport prior to 2.1.0 when management API authentication is left off, the factory configuration, as reported by The Hacker News^[1].

The mechanism: one POST, one stdio client, one command

Yuval Moravchick of JFrog Security Research reconstructed the full path. An attacker registers an stdio-type MCP client with an anonymous POST to the management endpoint /api/mcp/client.

Bifrost immediately launches the supplied command. The launch precedes any protocol handshake: the gateway executes first and validates afterwards. The process starts as the gateway user, which in the official Docker image is called appuser.

Here is the part that truly weighs on the risk profile. The gateway holds the API keys of every connected provider, so whoever executes commands inside that process reads those keys and buys tokens at the company's expense.

A single request is enough to go from the network to the entire organisation's credential wallet. The attack surface coincides with the administration endpoint, exposed with execution privileges and lacking any boundary between component registration and process launch. The disclosure timeline is also tracked in the public SecOpsNews thread^[2].

The twin flaw from early September

On 6 September 2026 the same research group disclosed CVE-2026-86242 (CVSS 8.1), found by Or Peles. An anonymous attacker registers a plugin whose path is an HTTP URL.

Bifrost downloads the file, writes it out as a temporary shared object and loads it with Go's plugin.Open function. On dynamically linked builds, which custom Go plugins require, the code runs as the gateway process user.

On static builds, including the official Docker image, plugin.Open fails and the impact drops to a server-side request forgery. The fix landed in transports/v2.0.0.

The two vulnerabilities share a precise root cause: the management API accepts anonymous registration of components that carry an execution capability with them. The rest is implementation detail. A launch capability enabled in the absence of boundaries always produces this class of incident.

Exposure: binary on localhost, container on 0.0.0.0

The standard Bifrost binary binds the management API to localhost. Exposure stays confined to the local machine, and that lowers the risk for anyone installing by hand.

The official Docker image, by contrast, binds to 0.0.0.0. Once the port is published, the administration API becomes reachable from outside the container.

The divergence between the two defaults deserves attention, because the Docker path is the one almost everyone picks in production. The most convenient deployment also turns out to be the most exposed: a classic of the agentic supply chain.

Anyone orchestrating the gateway with Kubernetes needs to re-read the Services and Ingresses that publish that port. A network rule remains the fastest defence while the update works its way through the release cycle, and it costs a few hours of work.

Version matrix: which patch covers what

The sequence of fixes requires careful reading, because an intermediate version leaves the main hole open.

• 1.6.x line up to 1.6.11: missing both fixes
• transports/v2.0.0: closes CVE-2026-86242, still vulnerable to anonymous MCP registration
• transports/v2.1.0: returns 403 to anyone attempting anonymous registration of an stdio MCP client

Anyone sitting on 2.0.0 believes they are covered while still exposing command execution. It is the kind of false sense of security that turns a partial patch into technical debt.

For those postponing the update, JFrog points to three measures: governance.auth_config.is_enabled set to true, strong credentials, and the management listener kept off open networks.

The researchers' closing advice is the hardest to swallow. Every instance that has run with authentication off and a reachable management API must be treated as compromised, with rotation of the virtual keys and of the API keys for all connected providers. Rotation costs a few hours compared with the bill for an LLM provider used by third parties for weeks.

The LLM gateway is a control plane

A component that concentrates the keys of twenty providers becomes a single point of compromise. The architecture diagram draws it as routing, but operational reality makes it a control plane capable of launching processes.

The security posture of AI systems runs two or three years behind the maturity of the rest of the infrastructure. Permissive defaults, open administration endpoints, components loaded at runtime: the same script as web apps in the 2000s and APIs in the decade that followed.

The MCP protocol amplifies the issue, because registering a client amounts to authorising a process. Treat registration as mere configuration and this is exactly the result you get.

The question to put to every gateway vendor remains a single one: what boundary separates the registration of a component from its execution?

Three questions for an enterprise AI team

A serious audit of the gateway layer starts with three measurable checks, to be closed out within the week.

1. Which version of the Bifrost transport is running in production, and is the management API reachable from outside the cluster?
2. Have the LLM provider API keys been rotated since the last period with authentication disabled?
3. Which other components of the agentic stack accept anonymous registrations carrying execution capability?

The third question produces the worst surprises. Tool registries, plugin runners, observability sidecars: plenty of them expose administration surfaces with the same implicit trust model inherited from the lab.

Anyone who answers all three with verifiable data has an inventory. Anyone answering from memory has a hypothesis, and in security a hypothesis is worth nothing. The result must be written down, with the version, the date of the check and the name of whoever signs off on it.

Decisions for the next planning cycle

For the CTO, the LLM gateway changes category in the systems register. It moves from middleware to critical component, with the access, logging and review rules that apply to a bastion host.

For the head of engineering, the minimum version becomes transports/v2.1.0 and the expected configuration has governance.auth_config.is_enabled set to true. A CI rule that blocks images with open management costs half a day of work.

For the CFO, the financial risk is direct and measurable. Stolen keys generate billable token consumption, and the cost of an incident far exceeds the spend on a secret manager and automated rotation.

For the procurement committee, contracts with gateway vendors need revisiting on two points: disclosure timelines and secure factory defaults. A vendor that ships with authentication off is offloading its own technical debt onto the customer.

Bifrost remains a serious project, with a team that fixes and documents its own flaws. The verdict concerns the factory configuration, and that needs changing before the next deployment.