--- title: "Network-AI Empty-Default-Secret Cross-Origin MCP Tool Invocation - CVE-2026-46701" description: "CVE-2026-46701: Network-AI's MCP SSE server defaults to an empty secret, so auth passes for everyone, and wildcard CORS lets any page call its 22 tools." url: "https://anomity.ai/blog/network-ai-empty-secret-cross-origin-mcp-cve-2026-46701/" source: html --- On this page - What happened - Why this is an agentic-endpoint risk - How Anomity surfaces and governs it - What to check across your fleet - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Network-AI Empty-Default-Secret Cross-Origin MCP Tool Invocation - CVE-2026-46701 ![Anomity robot illustrating Network-AI Empty-Default-Secret Cross-Origin MCP Tool Invocation - CVE-2026-46701] Advisory High # Network-AI Empty-Default-Secret Cross-Origin MCP Tool Invocation - CVE-2026-46701 Anomity Research Anomity Threat Research · May 21, 2026 · 6 min read Share: Copied 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. Coding-agent servers repeat the mistake: [OpenCode's local server](https://anomity.ai/blog/opencode-cross-site-upgrade-rce-ghsa-632h-h47v-g4x4/) accepted cross-site requests to an upgrade endpoint that installed arbitrary packages. 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](https://anomity.ai/blog/windows-mcp-unauthenticated-powershell-rce-ghsa-vrxg-gm77-7q5g/). ## 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](https://anomity.ai/#features) that get adopted bottom-up and report to no security tool - the dynamic that makes [AI agents and MCP servers the new shadow IT](https://anomity.ai/blog/ai-agents-are-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. Cross-origin MCP HTTP mistakes also land on developer loopback - covered in the [GitLab MCP DNS rebinding advisory](https://anomity.ai/blog/mcp-gitlab-streamable-http-dns-rebinding-cve-2026-61568/). ## 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](https://anomity.ai/#features) 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](https://anomity.ai/#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](https://anomity.ai/#outcomes), 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](https://anomity.ai/blog/mcp-server-security-complete-guide/). To see Anomity govern the MCP layer across your fleet, [book a demo](https://anomity.ai/#early-access). Share: Copied ## 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. ## Related [Advisory Critical ### mcp-atlassian HTTP Auth Bypass Falls Back to Global Credentials - CVE-2026-77254 CVE-2026-77254 (CVSS 9.1): unauthenticated HTTP MCP requests to mcp-atlassian below 0.22.0 fall through to globally configured Jira/Confluence credentials. Sibling CVE-2026-77244 (CVSS 10.0) accepts any non-empty token. Anomity Research · Sep 28, 2026 · CVE-2026-77254 (CVSS 9.1, GHSA-vc8m-84rp-53hx); sibling CVE-2026-77244 (CVSS 10.0, GHSA-wrhw-j3f9-8vc6)](https://anomity.ai/blog/mcp-atlassian-http-auth-bypass-global-credentials-cve-2026-77254/) [Advisory Critical ### GitLab MCP CVE-2026-61568 - Streamable HTTP DNS Rebinding to Localhost CVE-2026-61568 (CVSS 9.6): @zereight/mcp-gitlab Streamable HTTP skipped SDK DNS-rebinding Host/Origin allowlists on loopback - fixed in 2.1.30. Anomity Research · Sep 21, 2026 · CVE-2026-61568 (CVSS 9.6, GHSA-vmp7-252j-cwp7)](https://anomity.ai/blog/mcp-gitlab-streamable-http-dns-rebinding-cve-2026-61568/) [Advisory Critical ### MySQL MCP Server CVE-2026-59971 - Unauthenticated SQL via SSE DNS Rebinding CVE-2026-59971 (CVSS 10.0): mysql-mcp-server SSE mode skipped Host/Origin DNS-rebinding protection, bound 0.0.0.0 with no auth - unauthenticated SQL until 0.4.2. Anomity Research · Sep 21, 2026 · CVE-2026-59971 (CVSS 10.0, GHSA-rqfv-2mw9-78g2)](https://anomity.ai/blog/mysql-mcp-server-sse-dns-rebinding-unauth-sql-cve-2026-59971/) ## Structured data ```json { "@context": "https://schema.org", "@type": "TechArticle", "headline": "Network-AI Empty-Default-Secret Cross-Origin MCP Tool Invocation - CVE-2026-46701", "description": "CVE-2026-46701: Network-AI's MCP SSE server defaults to an empty secret, so auth passes for everyone, and wildcard CORS lets any page call its 22 tools.", "datePublished": "2026-05-21", "dateModified": "2026-05-21", "author": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ] }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/network-ai-empty-secret-cross-origin-mcp-cve-2026-46701/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/prompt-injection.jpg", "width": 1200, "height": 630 }, "articleSection": "MCP Server Security", "url": "https://anomity.ai/blog/network-ai-empty-secret-cross-origin-mcp-cve-2026-46701/", "keywords": "Network-AI empty secret MCP, CVE-2026-46701, MCP, SSE transport, authentication bypass, CORS, agentic AI security, CVE-2026-46701" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What exactly does CVE-2026-46701 let an attacker do?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "Where does the empty secret come from?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "How do I remediate it?", "acceptedAnswer": { "@type": "Answer", "text": "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." } }, { "@type": "Question", "name": "Why does wildcard CORS make the empty secret so much worse?", "acceptedAnswer": { "@type": "Answer", "text": "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." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Network-AI Empty-Default-Secret Cross-Origin MCP Tool Invocation - CVE-2026-46701", "item": "https://anomity.ai/blog/network-ai-empty-secret-cross-origin-mcp-cve-2026-46701/" } ] } ```