← Back to blog AdvisoryHigh

Network-AI Empty-Default-Secret Cross-Origin MCP Tool Invocation - CVE-2026-46701

Q: Where does the empty secret come from?

It originates in `bin/mcp-server.ts`, where a nullish-coalescing fallback supplies an empty string when no secret is provided at startup. The server then treats that empty string as a configured value and starts normally. The auth guard, `_isAuthorized`, was written to short-circuit to true when the secret is falsy - presumably intended as a development convenience - so the empty default silently disables authentication in the shipped configuration. Nothing fails closed and nothing warns the operator, which is what turns an insecure default into a remotely reachable bypass once the server is running and CORS is wildcarded.

Anomity Research Anomity Threat Research · May 21, 2026 · 6 min read

MCP Server Security·High·CVE-2026-46701·May 21, 2026

Affected Network-AI npm package (MCP SSE server, default configuration)

CVE-2026-46701 is a High-severity flaw in the Network-AI npm package: its MCP Server-Sent Events (SSE) server defaults to an empty secret, so the authorization check passes for every request, and it returns a wildcard CORS header that lets any web page read the responses. The result is unauthenticated, cross-origin invocation of all 22 exposed MCP tools against a default localhost server. This advisory covers what was disclosed, why it lands on the agentic-endpoint layer, and how to govern it.

What happened

The Network-AI npm package ships an MCP SSE server intended to run locally, and by default it starts with no secret configured. The empty value originates from a nullish-coalescing fallback in bin/mcp-server.ts, which supplies an empty string when no secret is passed at startup. The server treats that empty string as a valid configured secret and starts normally - no warning, no fail-closed behavior.

The authorization guard, _isAuthorized, checks whether the configured secret is falsy. An empty string is falsy, so the method returns true unconditionally for every request - no Authorization header required. In the default configuration the server therefore authenticates nobody and accepts everybody. Tracked as CVE-2026-46701, this is an authentication-bypass-by-insecure-default, not a credential leak.

The second half of the flaw is the transport. The SSE server sets Access-Control-Allow-Origin: * on every response, so the browser's same-origin policy no longer blocks a cross-origin page from reading results. An unauthenticated attacker who lures a user to a malicious page can have that page issue fetch calls to the local server and read what comes back. With authentication disabled and CORS wildcarded, the attacker can invoke all 22 exposed MCP tools against the default localhost instance - including config_set, agent_spawn, and blackboard_write, which rewrite configuration, launch new agents, and write to shared agent state.

Remediation requires a non-empty secret at startup that fails closed when none is set, a check that denies every request on a missing secret, and CORS restricted to localhost and 127.0.0.1 instead of wildcarding. The case combines an insecure default with permissive CORS - a recurring pairing across MCP server flaws, and the same auth-and-transport weakness seen in the Windows-MCP unauthenticated PowerShell RCE.

Why this is an agentic-endpoint risk

An MCP server is not a passive dependency. It is code an AI agent invokes to read state, change configuration, and spawn more agents, running with the agent's privileges on a managed endpoint. The Network-AI SSE server binds to localhost on a developer's machine, which feels safe - but localhost is where a browser-driven cross-origin attack lands. The controls you already run do not see it: the network sees only loopback traffic, EDR sees a legitimate node process, and DLP sees nothing at rest. The exposed surface lives in the AI artifact layer.

MCP servers are one of the eight AI artifact types that get adopted bottom-up and report to no security tool - the dynamic that makes AI agents and MCP servers the new shadow IT. A developer installs Network-AI to wire an agent into a workflow; the empty-secret default ships silently; and the server is now reachable by any tab the user opens. The question is not whether the package documents its default. It is which endpoints in your fleet are running a default-config Network-AI server right now, and which of its 22 tools they can reach - and you cannot answer that without an inventory of the artifact layer.

How Anomity surfaces and governs it

The durable defense is to inventory the MCP layer, treat each tool call as an execution boundary, and keep a record. Anomity does that in three steps.

First, inventory. Anomity inventories every MCP server on every managed endpoint as part of the eight AI artifact types it tracks, capturing the configuration metadata - transport, bound origin, whether a secret is set, and the agent that launches it. It classifies each server by trust signals and infers the tools it exposes, so a default-config Network-AI SSE server with no secret and wildcard CORS is visible as a finding, not an assumption. Metadata only: secrets are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example, the PreToolUse event in Claude Code - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. High-impact tools like config_set, agent_spawn, and blackboard_write can be denied at the boundary, so even if an attacker reaches the server, the call does not execute. That is the control runtime governance is built to provide while a fix rolls out.

Third, keep the record. Every decision, and every added, changed, or removed MCP server, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a CVE like this is published against a package you run, you can answer where it is, whether it was reachable, and which tools were called - from a record, not a guess. Anomity complements your Network, EDR, DLP, and GRC tooling; it covers the artifact layer those tools were never built to inventory.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

Inventory every MCP server on every endpoint and flag any Network-AI SSE server running its default configuration with no secret set.
Confirm each server requires a non-empty secret at startup and fails closed when none is provided - an empty Authorization value must be rejected, not accepted.
Check the CORS posture of every locally bound MCP server: a Access-Control-Allow-Origin: * header on a localhost server means any page the user visits can reach it.
Enumerate the tools each MCP server exposes and flag the high-impact ones - for Network-AI, config_set, agent_spawn, and blackboard_write.
Confirm high-risk tool calls are evaluated at the agent hook with allow/deny/log, so an unauthenticated cross-origin request cannot execute a tool.
Verify that every tool call and every server change is written to a 90-day audit trail and routed to your SIEM, so you can answer scope when the next insecure-default MCP CVE lands.

CVE-2026-46701 is the familiar pairing of an insecure default and permissive CORS, and the fix - a required secret and origin-scoped CORS - only protects endpoints that pick it up. The way through in the meantime is to inventory every MCP server, check its secret and CORS posture, and govern tool calls at the hook. For the full attack surface, trust tiers, and the 2026 CVE wave this sits within, see the pillar guide on MCP server security. To see Anomity govern the MCP layer across your fleet, request early access.

Frequently asked questions

What exactly does CVE-2026-46701 let an attacker do?

Network-AI's MCP SSE server ships with an empty default secret. Its _isAuthorized method only checks whether the configured secret is falsy, so an empty value makes authorization return true for every request, with no Authorization header needed. The same server sets Access-Control-Allow-Origin: * on every response. Together these mean a victim who is lured to a malicious web page lets that page's JavaScript reach the local server at localhost and read the results. The attacker can invoke all 22 exposed MCP tools, including config_set, agent_spawn, and blackboard_write, against the default localhost instance without ever authenticating.

Where does the empty secret come from?

It originates in bin/mcp-server.ts, where a nullish-coalescing fallback supplies an empty string when no secret is provided at startup. The server then treats that empty string as a configured value and starts normally. The auth guard, _isAuthorized, was written to short-circuit to true when the secret is falsy - presumably intended as a development convenience - so the empty default silently disables authentication in the shipped configuration. Nothing fails closed and nothing warns the operator, which is what turns an insecure default into a remotely reachable bypass once the server is running and CORS is wildcarded.

How do I remediate it?

Require a non-empty secret at startup and fail closed when none is set, rather than falling back to an empty string. Rewrite the authorization check so a missing or empty secret refuses every request instead of allowing it. Restrict CORS to the localhost and 127.0.0.1 origins the SSE server is meant to serve, instead of returning Access-Control-Allow-Origin: *. Until you can confirm the fixed configuration, treat any default-config Network-AI MCP server as reachable by any page the user visits, and govern its tool calls at the agent hook so high-impact tools like config_set and agent_spawn cannot run unattended.

Why does wildcard CORS make the empty secret so much worse?

On its own, an empty secret exposes the server to anything that can already reach localhost. Wildcard CORS removes the browser's same-origin protection, so any page the user opens can issue cross-origin fetches and read the responses. The two flaws compound: the auth bypass means no credential is needed, and the wildcard means the request can come from an attacker's tab rather than a local process. This pairing of an insecure default with permissive CORS recurs across MCP server flaws, which is why it is worth checking for both conditions together rather than either alone.