Most write-ups on Model Context Protocol (MCP) risk focus on what a malicious server tells your agent. This month's critical flaw in the Bifrost AI gateway is about something more basic. Telling a system to start an MCP server is the same as telling it to run a program, and in Bifrost anyone on the network could do it.
What happened
Bifrost is an open-source AI gateway that routes application traffic to many LLM providers and can register MCP clients through its management API. On 14 September, JFrog Security Research published CVE-2026-90898, rated CVSS 9.8. A stdio client registration accepts a command and arguments, and Bifrost starts that program as soon as the client is added. There is no MCP handshake first. The default setting is governance.auth_config.is_enabled=false, so every caller is treated as a local administrator.
The result was that one unauthenticated POST /api/mcp/client executed an arbitrary program as the gateway's process user. JFrog notes that the request may time out, but by then the process is already running. As The Hacker News reported, the attacker also lands in the process that holds the API keys for every connected provider. On Docker deployments the management API bound to 0.0.0.0 by default, so publishing the port exposed it.
The vendor's security update calls this "a gap in our defaults". Version 2.1.0 fixes it, along with a related unauthenticated plugin-registration issue (CVE-2026-86242, CVSS 8.1). Exploitation needs two conditions: the instance is reachable from the internet, and dashboard authentication was never set up. When The Hacker News published on 22 September, the flaw was not listed in CISA's Known Exploited Vulnerabilities catalog.
Why it happened: three reasonable defaults that compound
None of the individual decisions is unusual. Taken together, they give a full remote code execution chain:
- Authentication off by default. This is convenient for a first local run and dangerous once the gateway sits on a shared network.
- A listener on all interfaces in the container image. The admin surface was reachable wherever the port was published, not only from localhost.
- stdio registration means process creation. A stdio MCP server is a local program the host launches. Registering one is exec with JSON around it.
- A credential vault in the same process. A gateway concentrates provider keys by design, so a compromise of the gateway exposes all of them at once.
WorkOS's analysis makes a useful distinction: "Neither CVE was a flaw in an OAuth flow or a client-identity spec. Both were a privileged HTTP endpoint with nothing in front of it." The MCP specification says a lot about tool providers and consumers and much less about the management surfaces that decide which providers are trusted. Those management surfaces are where this bug was.
The pattern: MCP configuration is code
Leave Bifrost aside and the general rule is this: anything that can write an MCP server definition can run code on the machine that reads it. On a gateway, that is the management API. On a developer laptop, it is the JSON configuration files that Claude Code, Cursor, Copilot and similar tools read to start their MCP servers. Some of those files sit in the project repository, and some sit in the user's home directory.
So a coding agent that can edit those files, or a pull request that adds one, can install a new local program to be launched the next time a session starts. Usually that is legitimate work. Occasionally it is a prompt injection or a poisoned repository. Either way it deserves the same scrutiny you would give someone adding a startup script.
The controls that prevent it
For the gateway itself, the fixes from JFrog and the vendor are clear:
- Upgrade Bifrost to transports/v2.1.0 or later. Version 2.0.0 still allows unauthenticated stdio registration.
- Enable authentication (
governance.auth_config.is_enabled=true) with strong admin credentials and the setup token. - Restrict the management listener to trusted networks, and never publish it to the internet.
- If an instance was exposed without auth, treat it as compromised and rotate every virtual and provider API key it held.
A quick way to find admin surfaces listening on all interfaces on a host:
# Containers publishing ports on every interface
docker ps --format '{{.Names}}\t{{.Ports}}' | grep '0.0.0.0'
# Host processes listening on all interfaces
ss -ltnp | grep -E '0\.0\.0\.0|\[::\]'The more durable lessons apply to any AI infrastructure you deploy:
- Secure by default. Require authentication before first use, so it can't be skipped as an optional step. Adopt the same rule in your own internal tools.
- Treat MCP server registration as a privileged change. Keep an allowlist of approved servers, put review on whatever adds a new one, and log every change.
- Separate the key vault from the execution surface. Give the gateway process least privilege, and scope provider keys so that one compromise doesn't expose all of them.
- Inventory where MCP servers and gateways run. You can't rotate keys or patch hosts you don't know about.
Where agent guardrails fit, and where they don't
Endpoint policy would not have prevented this specific bug. It was a server-side flaw in a network service, and the fix is to patch, turn on authentication and close the port. Any vendor claiming otherwise is overselling.
The same pattern on developer endpoints is where allow / ask / deny policy helps. DarkControl evaluates each shell command, file write and network call that a coding agent attempts, so you can express the rules above directly:
- Ask before an agent starts an MCP server or a local AI gateway. Unmatched actions already default to Ask, so a new server process needs a human decision.
- Deny agent writes to MCP configuration files, or Ask for them, so a prompt-injected agent can't quietly register a new server for the next session.
- Allow the short list of approved MCP servers your teams actually use, scoped per department or group.
- Audit every attempt, including denied ones, so you can answer "where do MCP servers and gateways run, and who added them?" from evidence rather than guesses.
There is also a compliance side. NIS2 Article 21 requires security in the acquisition, development and maintenance of systems, including vulnerability handling. ISO 27001 Annex A 8.9 requires managed configurations. An AI gateway shipped with authentication off, and agent tooling that can change its own MCP config without review, both fall short of those controls. An immutable record of who changed what is the evidence auditors will ask for.
Want to see which MCP servers your coding agents start, and which config files they touch? DarkControl's free 7-day watch-only audit records it on up to 10 devices without blocking anything.
