A newly published CVE has exposed what may be the most straightforward MCP security flaw to date: a popular AI agent orchestration package that shipped with its local server completely open to unauthenticated cross-origin requests. No exploit kit required. No brute force. Just a browser tab and a user who happened to have the software running.
- An MCP security flaw in the Network-AI npm package handed full orchestrator access to any visiting web page with zero credentials required.
- The MCP security flaw stems from three lines of code: an empty default secret, an auth bypass for falsy values, and a wildcard CORS header.
- All 22 exposed MCP tools were reachable unauthenticated, including agent_spawn, blackboard_write, and token_revoke — not just read-only endpoints.
- The patched version 5.4.5 is on npm now; users should update immediately and set NETWORK_AI_MCP_SECRET explicitly in their environment.
What Network-AI Is — and Why It’s Worth Caring About
Network-AI is a TypeScript and Node.js library built to solve one of the messiest problems in multi-agent AI development: coordination. When you have several autonomous agents running in parallel and writing to shared state, race conditions happen fast. One agent overwrites another’s context, corruption spreads silently, and nothing throws an error. Network-AI addresses this with a shared blackboard architecture — atomic propose-validate-commit locking, HMAC and Ed25519 audit trails, per-agent token budgets, and finite state machine governance baked in.
It’s not a toy project. The library integrates with 17 AI frameworks including LangChain, AutoGen, CrewAI, OpenAI Assistants, and LlamaIndex. That kind of breadth puts it inside real production agentic workflows. It connects to those frameworks through a local Model Context Protocol (MCP) server running on port 3001 — and that local server is exactly where this MCP security flaw breaks down.
The MCP Security Flaw: Three Lines, One Open Door
CVE-2025-46701, published May 21, 2025, describes three individually innocuous-looking decisions that combine into a serious MCP security flaw. Read them separately and each one looks like a developer convenience. Read them together and you’ve got an unauthenticated remote-control interface exposed to every website a user visits.
First: In bin/mcp-server.ts, the server secret defaults to an empty string via a nullish coalescing fallback — process.env[‘NETWORK_AI_MCP_SECRET’] ?? ”. If the environment variable isn’t set, the secret is ”. Not null. Not undefined. An empty string.
Second: In the auth guard inside lib/mcp-transport-sse.ts, the _isAuthorized method checks whether the secret is falsy. An empty string is falsy in JavaScript. So if no secret is configured, the function returns true unconditionally — no Authorization header checked, no token validated, nothing. This is the second component of the MCP security flaw that makes silent bypass possible.
Third: The CORS header — Access-Control-Allow-Origin: * — is set before the auth check even runs. That ordering detail matters enormously. It means that even if a request would eventually be rejected, the browser has already been told it’s allowed to read the response from any origin.
Stack all three: any cross-origin request from any website reaches the MCP server’s JSON-RPC handler, gets authenticated automatically because the secret is empty, and the browser is explicitly permitted to read whatever comes back. The proof-of-concept in the advisory is blunt — an unauthenticated POST to /mcp from http://evil.example.com returns HTTP 200, isError: false, and config_set executes cleanly without a single token presented.
CVSS score: 7.6 High. Attack complexity: Low. Privileges required: None. That combination doesn’t leave much room for comfort.
What an Attacker Can Actually Do
This is where the story gets more serious than a typical auth bypass. The 22 MCP tools exposed through this MCP security flaw aren’t health-check endpoints or read-only status queries. The advisory specifically flags:
- config_set — mutate the orchestrator’s configuration arbitrarily
- agent_spawn — launch new agents inside the orchestrator
- blackboard_write and blackboard_delete — corrupt the shared state that every agent in the system is actively reading
- token_create and token_revoke — tamper with the permission token system that controls agent access
Think about what blackboard poisoning actually means in practice. The blackboard is the shared memory that every downstream agent in a Network-AI deployment reads from and writes to. An attacker who can write arbitrary data into it doesn’t just disrupt one agent — they feed bad state into the entire pipeline. Depending on what those agents are doing (browsing, writing code, making API calls, interacting with external services), the downstream consequences could extend well beyond the orchestrator itself.
Agent spawning is arguably just as dangerous. An attacker who can call agent_spawn from a malicious webpage can redirect the orchestrator’s work entirely — launching new agents with their own instructions while the user has no idea anything’s changed.
Token revocation rounds this out. Legitimate agents can be locked out. The system keeps running, happily, under attacker-controlled configuration. The advisory rates integrity impact as High. Confidentiality and availability are both rated Low — model weights and credentials aren’t directly accessible through the MCP API, and the service doesn’t go down. It just quietly does what the attacker wants.
Why This MCP Security Flaw Is Bigger Than One Package
The Network-AI vulnerability is a specific bug with a specific fix. But the underlying pattern — a local server on a fixed port, permissive CORS, auth that defaults to off — isn’t unique to this library. It’s almost a natural consequence of how MCP servers are designed to work, and it represents a category of MCP security flaw that other packages may share.
MCP servers are built to be easy to connect to from a client on the same machine. Claude Desktop, Cursor, VS Code extensions — they all connect to local MCP servers with minimal friction by design. “Easy to connect to locally” and “secure against cross-origin browser requests” aren’t automatically compatible goals. Keeping them from conflicting requires deliberate, explicit choices by every developer who ships an MCP server.
The MCP specification itself doesn’t mandate authentication. That responsibility falls entirely on individual implementations. When a library ships with an empty default secret and a ?? ” fallback, every developer who installs it and never sets NETWORK_AI_MCP_SECRET ends up running an open server — and the vast majority of them won’t know it. Each instance is effectively an undetected MCP security flaw waiting to be discovered. The developer experience of MCP is partly what’s made the ecosystem grow so fast. That same frictionlessness is also why this class of vulnerability is going to show up again.
Security researchers are already hunting the MCP ecosystem the way they hunt any production attack surface. CVE-2025-46701 is described by researchers as the first notable MCP security flaw of this kind, but it almost certainly won’t be the last. The ecosystem has grown from developer curiosity to genuine production infrastructure fast enough that the security community hasn’t fully caught up yet. That gap is closing.
The Fix and What You Should Do Now
The remediation outlined in the advisory is straightforward. Require a non-empty secret at startup. Fail fast and loudly if none is configured when running in SSE mode, rather than silently falling back to an open configuration. Restrict CORS to localhost and 127.0.0.1 origins instead of wildcarding everything. And move the CORS headers to after the auth check, so rejected requests don’t advertise cross-origin access in the first place.
Version 5.4.5 ships all of these changes and is on npm now. Affected versions are anything at or below 5.4.4. Credit for responsible disclosure goes to researchers identified as 232-323 and min8282, with the full advisory published at GHSA-j3vx-cx2r-pvg8.
If you’re running Network-AI as part of an agentic workflow — connected to Claude, Cursor, or VS Code via the MCP server — update to 5.4.5 today. More importantly, set NETWORK_AI_MCP_SECRET explicitly in your environment rather than relying on the default. A patched version with an unset secret still isn’t configured securely, and leaving it unset recreates the conditions of the original MCP security flaw.
The Broader Signal for AI Infrastructure Security
The MCP ecosystem is at an inflection point. What started as a clever protocol for connecting AI clients to local tools has become the connective tissue of a growing category of agentic AI infrastructure. Developers are building with it seriously, companies are shipping products on top of it, and the attack surface is expanding accordingly.
This particular MCP security flaw was caught before anyone hit a post-mortem. That’s genuinely good news — responsible disclosure worked, a patch shipped fast, and the advisory is detailed enough that the broader community can learn from it. But the lesson isn’t just “update Network-AI.” It’s that local-server architectures handling agent orchestration need to be treated with the same security rigor as any networked service. Default-open auth that made sense in a hackathon demo is a serious liability the moment real workloads start running on top of it. The MCP ecosystem is well past the hackathon stage now, and security practices need to catch up.
