Does CVE-2026-90898 affect Bifrost deployments that never use MCP?

The vulnerable path is the MCP client registration endpoint on the management API, so an attacker does not need your deployment to use MCP. The endpoint is present regardless. Reachability and management authentication are the conditions that matter.

Is patching to transports v2.1.0 sufficient on its own?

Patching closes the registration path. If an affected build was reachable from an untrusted network, treat the provider credentials the gateway held as potentially exposed and rotate them, then review the registered MCP clients for entries the team did not create.

Can an HTTP policy gateway block this attack?

No. The attack lands on a management endpoint and results in local process execution on the Bifrost host, which sits outside the HTTP path between authenticated users and LLM endpoints. Network segmentation, authentication on the management API, and the vendor patch are the controls that apply.

CVE-2026-90898: An AI Gateway That Runs Your Command Before the MCP Handshake

A single POST to /api/mcp/client is enough. Bifrost, the open-source AI gateway built by Maxim, accepts an MCP client definition on that endpoint. When the definition asks for the stdio transport, it carries a command and its arguments, because that is how a stdio MCP client is meant to start its server process. The gateway launches that program the moment the client is registered. No MCP handshake runs first, and in the affected releases nothing checks who sent the request.

Yuval Moravchick of JFrog Security Research found the behaviour. The Hacker News reported the disclosure on 22 September 2026, and the issue is tracked as CVE-2026-90898 with a CVSS score of 9.8. The command runs as the Bifrost process user.

TL;DR

CVE-2026-90898 lets an unauthenticated POST to Bifrost's /api/mcp/client endpoint register a stdio MCP client and execute its command, before any MCP handshake.
The exposure needs the management API reachable while management authentication is off, which is the documented default.
The fix is in transports v2.1.0. Earlier HTTP transport releases are affected.
No exploitation in the wild is reported, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog.
A traffic proxy does not remediate this. Patching, network placement, and credential rotation do.

The registration path

An MCP client definition tells a gateway how to reach an MCP server. HTTP transport points at a URL, while stdio transport points at a local program that the client starts and then talks to over standard input and output. The stdio shape is the one that carries a command field and an argument array.

Bifrost's management API accepts both. In the affected releases it starts the stdio process at registration time rather than waiting for a handshake or a tool call, so the attacker never needs a working MCP server. The registration request is the payload. That collapses the usual gap between configuring a thing and using it, and the gap is where most people expect an authorization check to live.

I think the interesting part is not the missing auth check. Plenty of tools ship with an open admin port. The interesting part is that an AI gateway's configuration language includes a field whose whole purpose is to name a program to execute, which means the config surface has the blast radius of a shell even when every other control is correct.

The configuration condition

Two things have to be true at once. The management API has to be reachable by the attacker, and governance.auth_config.is_enabled has to be false.

Authentication is off in the documented default, so the practical question for most teams is reachability. A stock binary binds to localhost. Bifrost's official Docker image binds to 0.0.0.0, which is normal for a container, and whether that reaches an untrusted network then depends on how the port is published and what sits in front of it. A Bifrost container behind a service mesh with no ingress route is in a different position from one published to a host port on a shared VPC subnet.

Triage on reachability first, because it takes one command to answer and it rules out most instances before anyone reads a version string.

Versions and the fix

The fix is in transports v2.1.0. HTTP transport releases before that are affected, so confirm the deployed version rather than the version in the README you read when the service went in. Check the running container image digest, not just the tag, because a floating tag can point somewhere you did not expect.

If the management API has been reachable from an untrusted network on an affected build, patching alone is not the whole response. Bifrost holds provider credentials and MCP configuration, which makes its control plane a production credential store. Rotate the provider keys it held, and review the MCP client list for entries nobody on the team registered.

Absent a KEV listing, this belongs on a normal urgent patch schedule rather than an out-of-hours page, and the credential rotation is the part teams tend to defer past the point where it helps.

Control plane and data plane

AI gateway threat models usually stop at the proxy: requests go in, policy applies, requests go out. The administrative surface gets treated as an internal convenience endpoint. CVE-2026-90898 is the argument against that split, and it is the same argument the LiteLLM MCP session authentication bypass made earlier this year. I wrote about that one in the LiteLLM CVE lessons piece, and the shape repeats: the control plane of an AI gateway is a higher-value target than the traffic flowing through it, because it holds the keys and defines the routes.

Keep the administrative control plane of any AI gateway authenticated and on a separate network path from the model-traffic data plane. Do not publish a management port to the same network segment that serves inference requests. Treat the gateway's own configuration as change-controlled security configuration, with a named owner and an approval record, the same way you treat a firewall rule.

Our MCP gateway security guide covers the transport-level questions in more depth, and the Bifrost comparison covers what the product does when it is configured correctly.

What to check this week

Find every AI gateway in the estate, including any instance a team stood up for a prototype and never decommissioned. For each, record the version, the bind address, whether management authentication is on, and which network can reach the management port.

Then check the MCP client registrations against a list of what should be there. An unexpected stdio entry is the artifact worth looking for, and it is cheap to check.

Finally, decide who owns the gateway's configuration. This is the question that tends to have no answer, because a service installed by a platform team and inherited by an application team often arrives with nothing but an endpoint URL.

DeepInspect

DeepInspect governs HTTP AI traffic between authenticated users or agents and LLM endpoints. It evaluates identity and prompt content on that path, enforces which model destinations are permitted, and writes a decision record for each request.

It does not patch Bifrost, stop a host process from launching, or rotate a provider key. Nothing in this CVE is inside its enforcement boundary, and a vendor who tells you otherwise is selling you a story. What stays true after the patch is the separate problem: once the gateway itself is secure, you still need an identity-bound record of which person or agent sent which prompt to which model.

Book a technical deep dive at deepinspect.ai.