GHSA-7HGR-7H44-33W2: Root-Cause Hardening for camofox-mcp HTTP Auth and Host Validation

Vulnerability

GHSA-7HGR-7H44-33W2 describes an unauthenticated access issue on the /mcp HTTP endpoint in camofox-mcp that could expose internal browser-control capability through a confused-deputy path. The supplied patch context indicates two concrete weaknesses in the HTTP transport: request authentication was not enforced early enough in the pipeline, and Host-header restrictions were insufficient for loopback or permissive binds. Together, those conditions increase the chance that an attacker can reach privileged MCP browser tooling without proper authorization, especially in deployments that expose the HTTP transport or rely on ambient trust.

The patch changelog explicitly states that Bearer authentication now runs before /mcp JSON body parsing, which is significant because pre-auth body parsing can leak parser behavior, consume resources, and process attacker-controlled input before access control is decided. The added tests also show a second class of risk: unexpected Host headers on loopback HTTP are now rejected, indicating prior susceptibility to host-header abuse or DNS rebinding-style access patterns. These observations are grounded in the commit at the upstream patch commit and the advisory at the GHSA record.

it("authenticates before parsing POST bodies", async () => {
  const response = await fetch(`${baseUrl}/mcp`, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: "{"
  });

  expect(response.status).toBe(401);
  const body = await response.text();
  expect(body).not.toMatch(/unexpected|json|syntax/i);
});

This regression test is strong evidence that the vulnerability involved incorrect middleware ordering: malformed JSON should no longer be parsed or surfaced before authentication rejects the request.

Patch

The patch replaces the prior direct MCP Express app construction with an explicit Express application and middleware composition in src/http.ts. The most important security changes are:

• Introduction of hostHeaderValidation from the MCP SDK middleware stack.
• Derivation of allowed host headers via getAllowedHostHeaders(config), including safe defaults for loopback binds such as localhost, 127.0.0.1, and [::1].
• Warning when binding to 0.0.0.0 or :: without explicit CAMOFOX_HTTP_ALLOWED_HOSTS, acknowledging residual DNS rebinding exposure if operators choose a broad bind.
• Explicit mounting of JSON parsing on /mcp after the earlier middleware setup, consistent with the changelog claim that authentication now precedes body parsing.
• Export of isLoopbackHost from src/config.ts so loopback-aware policy can be reused by the HTTP layer.
• Regression tests covering malformed unauthenticated POST bodies and hostile Host headers.

const app = express();
const allowedHostHeaders = getAllowedHostHeaders(config);
if (allowedHostHeaders) {
  app.use(hostHeaderValidation(allowedHostHeaders));
} else if (config.httpHost === "0.0.0.0" || config.httpHost === "::") {
  console.warn(
    `Warning: Server is binding to ${config.httpHost} without DNS rebinding protection. ` +
      "Set CAMOFOX_HTTP_ALLOWED_HOSTS when possible; CAMOFOX_HTTP_API_KEY is still required for this bind."
  );
}

app.use("/mcp", express.json());

Dependency updates to @modelcontextprotocol/sdk and express-rate-limit are present in package.json and package-lock.json, but the primary security value for this GHSA comes from the application-layer changes and tests rather than the version bumps alone. Source: commit 599f56e.

Review

Pros

• The patch addresses the access-control boundary at the correct layer: request validation and authentication are moved earlier in the HTTP pipeline, reducing pre-auth processing of attacker input.
• Host-header validation directly mitigates a realistic confused-deputy and DNS rebinding class of attacks for loopback-oriented deployments.
• The loopback default set is pragmatic and security-aware, covering common local access patterns without requiring manual configuration in the safest deployment mode.
• The new tests are meaningful, behavior-focused regressions rather than superficial coverage. They verify both malformed-body handling and Host-header rejection.
• The warning for wildcard binds is operationally useful and accurately communicates that API-key protection alone is not equivalent to DNS rebinding protection.

Cons

• The patch does not fully eliminate operator foot-guns: when binding to 0.0.0.0 or :: without CAMOFOX_HTTP_ALLOWED_HOSTS, the code emits a warning rather than enforcing a secure default. That leaves some protection dependent on deployment hygiene.
• The provided diff excerpt does not show the exact authentication middleware placement relative to all other middleware, so the review must infer ordering from the changelog and regression test rather than inspect the full final stack.
• Dependency upgrades may improve baseline security, but they are not by themselves a sufficient explanation of the vulnerability fix and could obscure the fact that the root issue was application configuration and middleware ordering.

Verdict

Root-cause.

This patch appears to remediate the underlying causes visible in the supplied sources: unauthenticated requests were allowed too far into request handling, and Host-header trust on local/default HTTP exposure was too permissive. By enforcing earlier rejection semantics and adding host-header validation with loopback-aware defaults, the patch closes the confused-deputy path in a technically appropriate way. The remaining caveat is deployment on wildcard interfaces without explicit allowed hosts, but that is surfaced as a documented and logged risk rather than silently ignored. Engineers should still follow the advisory guidance to upgrade and set CAMOFOX_HTTP_API_KEY; for non-loopback binds they should also define CAMOFOX_HTTP_ALLOWED_HOSTS. References: patch commit, official advisory, third-party report.