One HTTP Request Turns Bifrost AI Gateway Into a Shell

Key points

• Bifrost's management API starts any program a caller registers as an MCP client, and by default no login is required to call it.
• CVE-2026-90898 carries a CVSS score of 9.8.
• A single unauthenticated POST to /api/mcp/client runs a command as the Bifrost process user, which is appuser on the official container image.
• Version 2.1.0 of the HTTP transport blocks unauthenticated stdio registrations; 2.0.0 still accepts them.
• The default configuration ships with governance.auth_config.is_enabled set to false, so every caller is treated as a local administrator.

Bifrost is an open-source gateway that sits between an application and the large language model providers it talks to, routing requests to more than 20 back-ends including OpenAI and Anthropic. A flaw in how it registers helper programs lets anyone who can reach the gateway run commands on the server without a password.

The issue is tracked as CVE-2026-90898 and rated 9.8 out of 10.

How does the attack work?

Bifrost lets operators plug in MCP clients, small helper programs the gateway launches to extend what a model can do. A stdio client is described as a command plus its arguments. The moment an operator registers one through the management API, Bifrost starts that program. There's no handshake, no confirmation step.

So the registration call is the execution.

One unauthenticated POST to /api/mcp/client is enough to run a chosen binary as the Bifrost process user. On the official container image that user is appuser, which is enough to read secrets the gateway holds, including provider API keys, and to pivot from there. We've covered MCP-related security issues 13 times since June, and the pattern is consistent: the protocol's design makes the launch step a natural attack surface.

Why is authentication off by default?

Bifrost ships with governance.auth_config.is_enabled set to false. With auth off, the gateway treats every caller as a local admin. That's convenient on a laptop and dangerous on anything reachable from a network. The Hacker News, which first flagged the bug to a wider audience, noted the flaw affects every HTTP transport build before 2.1.0 when that switch is left at its default.

A decade watching this pattern: default-open admin APIs on infrastructure that ends up on the public internet are the 2020s equivalent of the unauthenticated Redis instance. The AI tooling boom is repeating the mistake at speed, and gateways holding provider keys are a rich target.

What changed in 2.1.0?

Upgrading the HTTP transport to 2.1.0 closes the specific path. Turning on governance.auth_config.is_enabled closes it on older builds too, and should be treated as mandatory anywhere the management port isn't firewalled off from the rest of the network.

What should operators do now?

Upgrade the HTTP transport to 2.1.0. If an upgrade has to wait, set governance.auth_config.is_enabled to true and restart the gateway, then confirm /api/mcp/client rejects an anonymous POST.

Check the MCP client list for entries no one recognises. Any stdio client registered while auth was off is a command that already ran, so treat the host as potentially touched and rotate every provider API key the gateway held. Container deployments should rebuild from a clean image rather than patch in place.

Restrict the management port to an internal network. A gateway routing to 20 LLM providers has no business answering admin calls from the public internet, patched or not.

Common questions

Does this affect Bifrost deployments behind a VPN?

If the management port isn't reachable from untrusted networks, the risk is contained to internal threat actors. That's a smaller population, not a safe one.

Is there any sign attackers have already used this?

Nothing in the public disclosure indicates confirmed exploitation, but our coverage of the Orkes Conductor pre-login flaw on 19 September 2026 showed how quickly opportunistic scanning follows a CVSS 9-plus publication.