Vulnerabilities in pkg:npm/camofox-mcp

PACKAGE
Advisory Summary

GHSA-7hgr-7h44-33w2 is a HIGH unauthenticated http mcp browser-control surface vulnerability (CWE-306: Missing Authentication for Critical Function) affecting CamoFox MCP libraries in the npm ecosystem. The issue involves unauthenticated http mcp browser-control surface. Remediation is available by upgrading affected packages to version 1.13.2.

1 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:npm/camofox-mcp

1 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:npm/camofox-mcp. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-7hgr-7h44-33w2 - HIGH CamoFox MCP: Unauthenticated HTTP MCP browser-control surface

GHSA-7hgr-7h44-33w2 at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-7hgr-7h44-33w2
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-306: Missing Authentication for Critical Function
Affected Product CamoFox MCP
Package Ecosystem npm
Published Date
Last Updated

How to Fix GHSA-7hgr-7h44-33w2

To remediate this vulnerability, upgrade all affected CamoFox MCP dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

camofox-mcp fixed: 1.13.2
npm install camofox-mcp@1.13.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls camofox-mcp

How to Check if You Are Affected

To determine whether your Node.js application is affected by GHSA-7hgr-7h44-33w2, inspect your project dependencies using npm:

npm ls camofox-mcp

Analyze the terminal output to locate any version of CamoFox MCP in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.13.2), your application is affected.

Note: The npm ls camofox-mcp command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-306: Missing Authentication for Critical Function, where the product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources. In CamoFox MCP, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

# Unauthenticated HTTP MCP browser-control surface in `camofox-mcp` ## Summary `camofox-mcp` exposed a Streamable HTTP MCP endpoint at `/mcp` with rate limiting but no inbound MCP-layer authentication. When HTTP mode was enabled, any client that could reach `/mcp` could list and invoke browser-control tools. If `CAMOFOX_API_KEY` was configured, the server then forwarded that server-side key to the underlying `camofox-browser` backend. That means an unauthenticated MCP caller could exercise the server's browser authority without knowing the backend browser API key. Reviewed vulnerable commit: `10e3ac08cb50d830eb4ee00a789229f02f28a1a4` Fixed commit observed on main: `599f56ee40f8062aeca541c251ed1d39fb437f50` Fixed release observed: `v1.13.2` Suggested severity: High, with the caveat that default loopback-only deployments reduce practical exposure. ## Root cause In the reviewed commit, `src/http.ts` creates the Express MCP app and applies only a rate limiter to `/mcp`: ```ts const app = createMcpExpressApp({ host: config.httpHost }); const limiter = rateLimit({ windowMs: 60_000, limit: config.httpRateLimit, standardHeaders: true, legacyHeaders: false }); app.use("/mcp", limiter); ``` The `POST /mcp` handler then creates a server and `StreamableHTTPServerTransport` and passes the request body into the MCP transport without checking `Authorization`, an inbound API key, allowed hosts, or public-bind safety: ```ts 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); ``` `src/config.ts` made HTTP mode configurable and defaulted the HTTP host to loopback, but it did not require an inbound HTTP client secret: ```ts transport: cli.transport ?? envTransport ?? "stdio", httpPort: cli.httpPort ?? (Number.isNaN(httpPortFromEnv) ? 3000 : httpPortFromEnv), httpHost: cli.httpHost ?? env.CAMOFOX_HTTP_HOST ?? "127.0.0.1", ``` Separately, `src/client.ts` forwarded `CAMOFOX_API_KEY` server-side to the browser backend: ```ts if (this.apiKey) { headers.set("x-api-key", this.apiKey); headers.set("authorization", `Bearer ${this.apiKey}`); } ``` So `CAMOFOX_API_KEY` protected the MCP server's outbound requests to the backend browser service, but did not authenticate inbound HTTP MCP clients. ## Auth boundary The vulnerable boundary was the HTTP MCP endpoint. The client did not need to provide `Authorization` or any `CAMOFOX_API_KEY` value to call MCP tools. The default bind was `127.0.0.1`, which lowers severity for default local-only deployments. The risky cases are documented HTTP/remote-client deployments, Docker/port-forwarded deployments, or any environment where a browser page, local network client, reverse proxy, or another user can reach the `/mcp` endpoint. ## Proof of concept I used a fake `camofox-browser` backend so no real browser was launched and no external navigation occurred. The harness starts the reviewed `dist/http.js` server with `CAMOFOX_API_KEY=server-side-secret`, connects an MCP SDK client to `/mcp` with no auth headers, lists tools, then calls `create_tab` and `navigate`. Observed output: ```json { "authUsedByClient": false, "listedToolCount": 46, "backendRequests": [ { "method": "POST", "url": "/tabs", "headers": { "authorization": "Bearer server-side-secret", "x-api-key": "server-side-secret" } }, { "method": "POST", "url": "/tabs/fake-tab-1/navigate", "headers": { "authorization": "Bearer server-side-secret", "x-api-key": "server-side-secret" } } ], "observedUnauthenticatedBrowserControl": true, "serverSideSecretForwardedToBackend": true } ``` This demonstrates both parts of the issue: 1. The MCP client used no inbound authentication. 2. The server still used its configured backend browser secret when forwarding the tool calls. ## Impact An unauthenticated client that can reach the HTTP MCP endpoint can exercise browser-control tools as the MCP server. Depending on the user's active browser profiles and configured backend, that can allow page navigation, tab creation, interaction with authenticated browser contexts, screenshot/content observation, and other browser-automation actions exposed by the MCP tool surface. The impact is strongest when HTTP mode is intentionally exposed for remote MCP clients or through Docker/reverse-proxy deployment and the operator assumes `CAMOFOX_API_KEY` protects the whole control plane. ## Fix notes The public issue indicates this has been fixed in `599f56e` and released as `v1.13.2` by adding dedicated inbound `CAMOFOX_HTTP_API_KEY` Bearer auth, public-bind startup validation, auth before `/mcp` JSON parsing, loopback Host-header protection, and optional allowed-hosts handling. Those are the right mitigation directions.

GHSA-7hgr-7h44-33w2 Affected CamoFox MCP Versions

1 component(s)
Fixed Versions:
1.13.2
Product / Package Ecosystem Affected Versions Fixed Version
camofox-mcp
npm
< 1.13.2
1.13.2

References

Frequently Asked Questions

What is GHSA-7hgr-7h44-33w2?
GHSA-7hgr-7h44-33w2 is a security vulnerability in CamoFox MCP involving Unauthenticated HTTP MCP browser-control surface under CWE-306: Missing Authentication for Critical Function.
Which CamoFox MCP versions are affected?
Affected versions include releases prior to 1.13.2 across affected packages: camofox-mcp.
What version fixes GHSA-7hgr-7h44-33w2?
Upgrading to 1.13.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is camofox-mcp affected?
Yes, camofox-mcp is affected in releases prior to 1.13.2. Upgrade your dependency to 1.13.2 or later.
What CWE is associated with GHSA-7hgr-7h44-33w2?
GHSA-7hgr-7h44-33w2 is classified under CWE-306: Missing Authentication for Critical Function (The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.).
How can I check npm dependencies for GHSA-7hgr-7h44-33w2?
Run the dependency tree command: 'npm ls camofox-mcp'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-7hgr-7h44-33w2",
  "modified" : "2026-05-19T20:13:35Z",
  "published" : "2026-05-19T20:13:35Z",
  "aliases" : [ ],
  "summary" : "CamoFox MCP: Unauthenticated HTTP MCP browser-control surface",
  "details" : "# Unauthenticated HTTP MCP browser-control surface in `camofox-mcp`\n\n## Summary\n\n`camofox-mcp` exposed a Streamable HTTP MCP endpoint at `/mcp` with rate limiting but no inbound MCP-layer authentication. When HTTP mode was enabled, any client that could reach `/mcp` could list and invoke browser-control tools.\n\nIf `CAMOFOX_API_KEY` was configured, the server then forwarded that server-side key to the underlying `camofox-browser` backend. That means an unauthenticated MCP caller could exercise the server's browser authority without knowing the backend browser API key.\n\nReviewed vulnerable commit: `10e3ac08cb50d830eb4ee00a789229f02f28a1a4`\nFixed commit observed on main: `599f56ee40f8062aeca541c251ed1d39fb437f50`\nFixed release observed: `v1.13.2`\nSuggested severity: High, with the caveat that default loopback-only deployments reduce practical exposure.\n\n## Root cause\n\nIn the reviewed commit, `src/http.ts` creates the Express MCP app and applies only a rate limiter to `/mcp`:\n\n```ts\nconst app = createMcpExpressApp({ host: config.httpHost });\n\nconst limiter = rateLimit({\n  windowMs: 60_000,\n  limit: config.httpRateLimit,\n  standardHeaders: true,\n  legacyHeaders: false\n});\n\napp.use(\"/mcp\", limiter);\n```\n\nThe `POST /mcp` handler then creates a server and `StreamableHTTPServerTransport` and passes the request body into the MCP transport without checking `Authorization`, an inbound API key, allowed hosts, or public-bind safety:\n\n```ts\napp.post(\"/mcp\", async (req: any, res: any) => {\n  try {\n    const { server } = createServer(config);\n    const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });\n\n    await server.connect(transport);\n    await transport.handleRequest(req, res, req.body);\n```\n\n`src/config.ts` made HTTP mode configurable and defaulted the HTTP host to loopback, but it did not require an inbound HTTP client secret:\n\n```ts\ntransport: cli.transport ?? envTransport ?? \"stdio\",\nhttpPort: cli.httpPort ?? (Number.isNaN(httpPortFromEnv) ? 3000 : httpPortFromEnv),\nhttpHost: cli.httpHost ?? env.CAMOFOX_HTTP_HOST ?? \"127.0.0.1\",\n```\n\nSeparately, `src/client.ts` forwarded `CAMOFOX_API_KEY` server-side to the browser backend:\n\n```ts\nif (this.apiKey) {\n  headers.set(\"x-api-key\", this.apiKey);\n  headers.set(\"authorization\", `Bearer ${this.apiKey}`);\n}\n```\n\nSo `CAMOFOX_API_KEY` protected the MCP server's outbound requests to the backend browser service, but did not authenticate inbound HTTP MCP clients.\n\n## Auth boundary\n\nThe vulnerable boundary was the HTTP MCP endpoint. The client did not need to provide `Authorization` or any `CAMOFOX_API_KEY` value to call MCP tools.\n\nThe default bind was `127.0.0.1`, which lowers severity for default local-only deployments. The risky cases are documented HTTP/remote-client deployments, Docker/port-forwarded deployments, or any environment where a browser page, local network client, reverse proxy, or another user can reach the `/mcp` endpoint.\n\n## Proof of concept\n\nI used a fake `camofox-browser` backend so no real browser was launched and no external navigation occurred. The harness starts the reviewed `dist/http.js` server with `CAMOFOX_API_KEY=server-side-secret`, connects an MCP SDK client to `/mcp` with no auth headers, lists tools, then calls `create_tab` and `navigate`.\n\nObserved output:\n\n```json\n{\n  \"authUsedByClient\": false,\n  \"listedToolCount\": 46,\n  \"backendRequests\": [\n    {\n      \"method\": \"POST\",\n      \"url\": \"/tabs\",\n      \"headers\": {\n        \"authorization\": \"Bearer server-side-secret\",\n        \"x-api-key\": \"server-side-secret\"\n      }\n    },\n    {\n      \"method\": \"POST\",\n      \"url\": \"/tabs/fake-tab-1/navigate\",\n      \"headers\": {\n        \"authorization\": \"Bearer server-side-secret\",\n        \"x-api-key\": \"server-side-secret\"\n      }\n    }\n  ],\n  \"observedUnauthenticatedBrowserControl\": true,\n  \"serverSideSecretForwardedToBackend\": true\n}\n```\n\nThis demonstrates both parts of the issue:\n\n1. The MCP client used no inbound authentication.\n2. The server still used its configured backend browser secret when forwarding the tool calls.\n\n## Impact\n\nAn unauthenticated client that can reach the HTTP MCP endpoint can exercise browser-control tools as the MCP server. Depending on the user's active browser profiles and configured backend, that can allow page navigation, tab creation, interaction with authenticated browser contexts, screenshot/content observation, and other browser-automation actions exposed by the MCP tool surface.\n\nThe impact is strongest when HTTP mode is intentionally exposed for remote MCP clients or through Docker/reverse-proxy deployment and the operator assumes `CAMOFOX_API_KEY` protects the whole control plane.\n\n## Fix notes\n\nThe public issue indicates this has been fixed in `599f56e` and released as `v1.13.2` by adding dedicated inbound `CAMOFOX_HTTP_API_KEY` Bearer auth, public-bind startup validation, auth before `/mcp` JSON parsing, loopback Host-header protection, and optional allowed-hosts handling. Those are the right mitigation directions.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "camofox-mcp"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.13.2"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/redf0x1/camofox-mcp/security/advisories/GHSA-7hgr-7h44-33w2"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/redf0x1/camofox-mcp/commit/599f56ee40f8062aeca541c251ed1d39fb437f50"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/redf0x1/camofox-mcp"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-306" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-19T20:13:35Z",
    "nvd_published_at" : null
  }
}