GHSA-r78r-rwrf-rjwp
CRITICALGHSA-r78r-rwrf-rjwp is a critical-severity (CVSS 9.1) Missing Authentication vulnerability in network-ai. O3 Security confirms whether GHSA-r78r-rwrf-rjwp is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Network-AI: CVE-2026-46701 fix incomplete — empty default secret still authorizes all requests
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.
Exploitation and automatability from CISA’s SSVC triage for GHSA-r78r-rwrf-rjwp.
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-r78r-rwrf-rjwp 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 357,322 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.
network-ainpmDescription
Advisory / Disclosure
Network-AI — CVE-2026-46701 fix is incomplete: the "Empty Default Secret" unauth path survives
Target: Jovancoding/Network-AI (npm network-ai), latest v5.7.1
Status: the advisory ("Unauthenticated Cross-Origin MCP Tool Invocation via Empty
Default Secret") named three flaws. The fix (5.4.5) closed the CORS flaw
(Access-Control-Allow-Origin is now set only for localhost origins), but left the
empty-default-secret flaw the title is about: the SSE MCP server still defaults to an
empty secret, _isAuthorized() still returns true when the secret is empty, and a
non-loopback bind only warns. So the server still runs fully unauthenticated by
default — any non-browser caller (curl, SSRF, or a 0.0.0.0 bind) can invoke all 22 MCP
tools (config_set, agent_spawn, blackboard_write, token_*) with no credentials.
Class: CWE-306/CWE-862 Missing Authentication — incomplete fix.
Methodology: M1 incomplete-fix audit (anchor = the 5.4.5 fix; sibling-walk on latest v5.7.1, executed).
Severity: High (matches parent; the browser amplifier is removed, so exploitation now
needs non-browser reach — SSRF or a non-loopback bind, which the fix only warns about).
What the fix did and didn't do (verified on latest v5.7.1)
| advisory flaw | latest v5.7.1 |
|---|---|
wildcard CORS (ACAO: *) | FIXED — lib/mcp-transport-sse.ts sets ACAO only when origin matches ^https?://(localhost|127\.0\.0\.1)(:\d+)?$ |
| empty default secret | NOT FIXED — bin/mcp-server.ts: secret: process.env['NETWORK_AI_MCP_SECRET'] ?? '' |
_isAuthorized open on empty secret | NOT FIXED — if (!this._opts.secret) return true; |
| require secret / refuse unauth bind | NOT DONE — listen() only process.stderr.write('… WARNING …') on non-loopback bind, then listens anyway |
The advisory's remediation #1 ("Require a non-empty secret at startup … process.exit(1)")
was not implemented.
PoC (executed against the latest source, v5.7.1) — poc/legend-networkai-empty-secret.ts
Instantiates the real McpSseServer from the latest lib/ with a mock bridge and the
default (empty) secret, then issues requests (run-log poc/run-log.txt):
POST /mcp no-auth, no-origin (curl/SSRF) -> HTTP 200, dispatched=true
body: {"jsonrpc":"2.0","id":1,"result":{"executed":true,"tool":"config_set"}}
POST /mcp Origin: evil.example.com -> ACAO=undefined (CORS half fixed)
The no-auth request passes _isAuthorized and reaches handleRPC (tool dispatched) — i.e.
unauthenticated tool invocation persists on the latest release; only the browser-CORS read
amplifier was removed.
Run: from a v5.7.1 checkout, npm i then
npx ts-node --transpile-only poc/legend-networkai-empty-secret.ts.
Recommended fix
Implement the advisory's remediation #1: refuse to start SSE mode with an empty secret
(unless --stdio), and/or change _isAuthorized to fail closed (an empty configured
secret should mean "deny", not "allow"). The CORS allowlist alone does not authenticate
non-browser callers.
Precondition / honesty
With CORS now localhost-only, the drive-by browser attack is mitigated. The residual
requires a non-browser path to the port: an SSRF on the host, or the operator binding to a
non-loopback address (Docker/remote), which the fix only warns about. The empty secret
remains the shipped default and _isAuthorized still authorizes it.
Credits
@Kai Aizen / @SnailSploit — https://snailsploit.com
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | network-ai | all versions | 5.7.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for network-ai. 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 network-ai to 5.7.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-r78r-rwrf-rjwp 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-r78r-rwrf-rjwp 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-r78r-rwrf-rjwp. 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-r78r-rwrf-rjwp in your dependencies?
O3 detects GHSA-r78r-rwrf-rjwp across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.