GHSA-7HGR-7H44-33W2: Unauthenticated Browser Control via Confused Deputy in camofox-mcp

The camofox-mcp package operates as a server implementation for the Model Context Protocol (MCP), providing extensive browser automation capabilities. It exposes an HTTP transport endpoint at /mcp that clients use to interact with the underlying browser tools. Prior to version 1.13.2, this endpoint was implemented without any inbound authentication mechanisms, relying solely on rate limiting for traffic management.

This lack of authentication constitutes a Missing Authentication for Critical Function vulnerability (CWE-306). Any client capable of routing HTTP traffic to the server port can invoke the MCP interface. The server accepts these unauthenticated connections and establishes a transport stream, assuming the client possesses the necessary authorization to interact with the system.

The vulnerability is compounded by a Confused Deputy condition (CWE-441) in the server's architecture. The MCP server acts as an intermediary between external clients and the internal headless browser backend. While the backend requires an API key, the MCP server automatically attaches its own configured key to all forwarded requests. Consequently, an unauthenticated external attacker inherits the server's elevated privileges.

Successful exploitation results in total compromise of the browser automation environment. Attackers can list available system tools, spawn new browser tabs, navigate to arbitrary URLs, and extract content or screenshots. While default configurations binding to 127.0.0.1 limit external exposure, environments utilizing Docker or reverse proxies frequently expose this endpoint to broader networks.

The structural flaw originates in the initialization sequence of the Express application within src/http.ts. The implementation defined a rate limiter to throttle inbound traffic to the /mcp route, establishing a baseline of network control. However, the middleware stack completely lacked an authorization verifier to validate the identity of the invoking client.

When a client submits a POST /mcp request, the routing logic directly constructs a StreamableHTTPServerTransport object. The application then connects this transport stream to the backend MCP server without challenging the client for a Bearer token or any shared secret. The transport handles the request and parses the incoming payload, assuming the external source is legitimate.

The critical failure occurs downstream during the backend communication phase in src/client.ts. The server configuration dictates that if a CAMOFOX_API_KEY is present in the environment, the server must append this key to both the x-api-key and authorization headers for outbound traffic. This design strictly protects the backend service from the MCP server, but it creates a blind proxy situation.

Because the MCP server blindly forwards all unauthenticated inbound requests to the backend using its own administrative credentials, it functions as a Confused Deputy. The system architecture mistakenly conflated the authentication required for inter-process communication with the authorization required for external client access, leaving the public-facing endpoint entirely defenseless.

An examination of the vulnerable implementation in src/http.ts highlights the absence of access controls before the transport layer execution. The Express application registers the rate limiter and immediately defines the POST handler, which allocates the transport and processes the body payload.

// src/http.ts (Vulnerable)
const app = createMcpExpressApp({ host: config.httpHost });
 
const limiter = rateLimit({
  windowMs: 60_000,
  limit: config.httpRateLimit,
  standardHeaders: true,
  legacyHeaders: false
});
 
app.use("/mcp", limiter);
 
app.post("/mcp", async (req: any, res: any) => {
  try {
    const { server } = createServer(config);
    const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
 
    await server.connect(transport);
    await transport.handleRequest(req, res, req.body);
    // ...

The patch introduced in commit 599f56ee40f8062aeca541c251ed1d39fb437f50 comprehensively addresses this failure. The developers introduced a mandatory authentication middleware utilizing a static token verifier. This implementation enforces Bearer authentication strictly on the /mcp route before any further processing occurs.

// src/http.ts (Fixed)
  app.use("/mcp", limiter);
 
  if (config.httpApiKey) {
    app.use(
      "/mcp",
      requireBearerAuth({
        verifier: createStaticTokenVerifier(config.httpApiKey)
      })
    );
  }
 
  app.use("/mcp", express.json()); // Body parsing now happens AFTER auth check

Crucially, the middleware stack was reordered to perform the authorization validation before the execution of express.json(). This precise placement ensures that unauthenticated payloads are rejected immediately, significantly reducing the attack surface for potential denial-of-service or JSON parser vulnerabilities.

Exploitation requires the attacker to establish a network route to the vulnerable /mcp HTTP endpoint. In default configurations, this restricts the attack vector to local users or server-side request forgery (SSRF) primitives. However, in containerized deployments where the port is explicitly mapped to external interfaces, the endpoint becomes accessible to remote adversaries.

The attack begins with reconnaissance against the MCP interface. The attacker transmits an unauthenticated request to the server to list the available tools. Because the server forwards this query using its internal credentials, the backend responds with a comprehensive inventory of browser-control functions, mapping the internal attack surface for the adversary.

Once the capabilities are mapped, the active exploitation phase commences. The attacker constructs a POST payload specifying an administrative action, such as executing create_tab or navigate. The payload is transmitted to the MCP endpoint, where the server appends the CAMOFOX_API_KEY and passes the instruction to the headless browser.

The maintainers' reproduction harness successfully demonstrated this behavior. The proof-of-concept output confirmed that a client supplying no credentials ("authUsedByClient": false) could enumerate tools ("listedToolCount": 46) and trigger backend requests containing the server-side-secret. This conclusively validates the Confused Deputy mechanism.

The security impact of this vulnerability is severe for exposed instances, resulting in arbitrary control over the headless browser context. An attacker leveraging this flaw achieves remote code execution equivalence within the browser environment, allowing them to initiate arbitrary web requests originating from the targeted server.

The most immediate threat involves data exfiltration and session hijacking. Adversaries can utilize the get_content or screenshot tools to capture sensitive information currently rendered in the browser. Furthermore, if the server-side browser maintains authenticated sessions with internal infrastructure, the attacker can hijack these sessions to compromise adjacent systems.

The vulnerability is assessed with a High severity rating under CVSS v4.0 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:H/SI:H/SA:L). The scoring reflects the low attack complexity and lack of required privileges, heavily weighted by the severe secondary impacts on the backend browser systems and the potential for lateral movement.

Risk exposure is primarily dictated by the deployment topology. Standard local installations relying on the default loopback binding inherently mitigate remote exploitation. Conversely, organizations operating camofox-mcp within Docker Swarm, Kubernetes, or behind misconfigured reverse proxies face immediate risk of automated discovery and exploitation.

The primary remediation for this vulnerability is an immediate upgrade to camofox-mcp version 1.13.2 or later. The patched release implements structural changes to the HTTP transport layer, establishing mandatory authentication checkpoints and preventing unauthenticated interactions with the backend service.

Post-upgrade, administrators must define the CAMOFOX_HTTP_API_KEY environment variable. Supplying a strong, cryptographically secure string ensures that the Express middleware verifies the Bearer token for all incoming requests. Without this configuration, the server refuses to initialize on external network interfaces, failing closed by design.

The patched version introduces two critical defense-in-depth mechanisms to protect configurations. First, the secure binding policy prevents the application from starting on 0.0.0.0 or public IPs unless the inbound API key is configured. Second, the developers implemented strict host-header validation (CAMOFOX_HTTP_ALLOWED_HOSTS) to neutralize DNS rebinding attacks targeting local interfaces.

In environments where upgrading is temporarily impossible, network operators must enforce strict ingress filtering. The port hosting the /mcp endpoint must be firewalled and restricted exclusively to trusted local services. Reverse proxies should be configured to inject and enforce custom authentication tokens before traffic reaches the vulnerable application.