MCP Connect Default-Unauthenticated /bridge Endpoint OS Command Execution - GHSA-wvr4-3wq4-gpc5

A critical missing-authentication flaw, tracked as GHSA-wvr4-3wq4-gpc5, was disclosed in MCP Connect, the bridge project published as mcp-bridge. Its HTTP /bridge endpoint relays network requests directly to local MCP servers and spawns subprocesses from request parameters - and in the default configuration it does so with no authentication at all. Every version up to and including 2.0.0 is affected, and no fixed release was available at disclosure. This advisory covers what was reported, why it lands on the agentic-endpoint layer, and how to govern it while there is no patch.

What happened

MCP Connect, distributed as mcp-bridge, exposes an HTTP /bridge endpoint whose job is to relay incoming network requests straight to local MCP servers, dynamically spawning subprocesses from the parameters carried in each request. The flaw, GHSA-wvr4-3wq4-gpc5, is classified as CWE-306, missing authentication for a critical function: the endpoint only enforces credentials when the AUTH_TOKEN and ACCESS_TOKEN environment variables are both explicitly set. In the default out-of-the-box configuration, both are unset, so the endpoint is fully unauthenticated.

Because the endpoint spawns subprocesses from request data, any attacker with network access to it can execute arbitrary OS commands as the user running mcp-bridge. The reported impact is full host compromise: credential and secret theft from the process environment, backdoor persistence, lateral movement to other reachable systems, and data destruction. All versions up to 2.0.0 are affected and there was no fixed release at disclosure. The interim guidance is direct - set both tokens and prevent any network exposure of the bridge by keeping it bound to localhost or an internal-only interface.

This is the same root pattern that runs through the 2026 MCP CVE wave: an MCP component that turns network input into local process execution with no authentication in front of it. It sits beside disclosures like the MCP Inspector proxy unauthenticated RCE and the nginx-ui unauthenticated MCP takeover, where a default-open surface, not an exotic exploit, is what hands over the host.

Why this is an agentic-endpoint risk

A bridge like mcp-bridge is not a passive dependency. It is the glue that lets an AI agent reach local MCP servers, and it runs subprocesses with the privileges and environment of whoever started it on a managed endpoint. The unauthenticated /bridge endpoint sits on the everyday path between an agent and its tools, which is why a missing-auth default here is a fleet problem rather than a single misconfigured box.

The exposure is hard to see from the controls you already run, because it lives in the AI artifact layer. A developer installs mcp-bridge to unblock a task and binds it to a reachable interface; the spawned processes look legitimate to EDR; the network sees ordinary HTTP to a local port; and DLP sees nothing at rest. MCP servers and bridges are among the eight AI artifact types adopted bottom-up that report to no security tool - the dynamic that makes AI agents and MCP servers the new shadow IT. The question is not whether the endpoint is documented as token-gated; it is which endpoints actually run mcp-bridge with the tokens unset and the port reachable, and you cannot answer that without an inventory of the artifact layer.

How Anomity surfaces and governs it

Because there was no patch at disclosure, the durable defense is to treat the bridge's subprocess spawns as an execution boundary and govern which calls are allowed to run. Anomity does that in three steps.

First, inventory. Anomity inventories every MCP server and bridge on every managed endpoint as part of the eight AI artifact types it tracks, capturing the configuration metadata - including whether mcp-bridge is present, what interface its /bridge endpoint binds to, and whether AUTH_TOKEN and ACCESS_TOKEN are set. It classifies each artifact by trust signals and infers the capabilities it grants. Metadata only: secrets are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example, the PreToolUse event in Claude Code - Anomity evaluates each tool call and process spawn against your policy and returns allow, deny, or log before the call runs. A subprocess spawn driven through an unauthenticated bridge can be denied at the boundary instead of executing, which is exactly the control runtime governance is built to provide while a fix is outstanding.

Third, keep the record. Every decision, and every added, changed, or removed MCP artifact, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a flaw like GHSA-wvr4-3wq4-gpc5 is published against a tool you run, you can answer where mcp-bridge is, how it was configured, what it was allowed to do, and what it did - from a record, not a guess. Anomity complements your Network, EDR, DLP, and GRC tooling; it covers the artifact layer those tools were never built to inventory.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint running MCP Connect / mcp-bridge and flag any at version 2.0.0 or earlier as in-scope for GHSA-wvr4-3wq4-gpc5.
• Confirm that both the AUTH_TOKEN and ACCESS_TOKEN environment variables are set on every bridge instance - an unset pair means the /bridge endpoint is fully unauthenticated.
• Verify the bridge binds to localhost or an internal-only interface, and that no firewall rule, tunnel, or port-forward exposes the /bridge endpoint to a reachable network.
• Identify what privileges and environment the bridge process runs as, since arbitrary commands execute as that user with access to its secrets.
• Confirm that subprocess spawns driven through the bridge are evaluated at the agent hook with allow/deny/log, so an unauthenticated command is stopped before it runs.
• Verify that every spawn and every bridge configuration change is written to a 90-day audit trail and routed to your SIEM, so you can answer scope questions when a fixed release ships.

GHSA-wvr4-3wq4-gpc5 is a default-open endpoint that turns network reach into host compromise, and at disclosure there was no version to upgrade to. The way through is to set both tokens, keep the bridge off any reachable network, and govern its spawns at the hook. For the full attack surface, trust tiers, and the 2026 CVE wave this class sits within, see the pillar guide on MCP server security. To see Anomity inventory and govern the MCP layer across your fleet, request early access.