Eight fixes in the official MCP servers show where an agent's tool can exceed the access it was given
The Model Context Protocol maintainers fixed eight vulnerabilities in the filesystem, everything and fetch reference servers. Each one is a boundary the tool, not the agent, was supposed to hold.
Listen to this article · 5 min
AI-generated narration of the full article.
A developer is testing an agent locally. The MCP server it uses runs over HTTP so a second tool can reach it, and the developer’s shell holds a cloud key in an environment variable. In another browser tab, the developer opens an ordinary web page. Until October 25, if that server was the official server-everything package, the page could call a tool that returns the process’s environment variables and read the key.
No model made a mistake in that scenario. The agent’s instructions, permissions and guardrails were irrelevant. The tool server itself was reachable by anyone who could get a browser to send a request.
That case is one of eight vulnerabilities fixed on October 25 in version 2.1.0 of the official Model Context Protocol servers repository, across three reference servers: filesystem, everything and fetch. None of them is in the MCP specification. All of them are in the layer that turns “the agent may use this tool” into what the tool can actually touch.
Each fix restores a boundary the tool was supposed to hold
| What went wrong | Boundary restored | Fixed in | |
|---|---|---|---|
| filesystem (4 fixes) | Symlink swaps redirecting writes, a path check that trimmed quotes and spaces, case-variant symlinks, file sizes leaking through directory listings | The allowed directories | 2.0.1 |
| everything (1 fix) | HTTP and SSE transports open to any web origin, with no authentication | The developer's machine and its secrets | 2.0.1 |
| fetch (3 fixes) | Host name checked in one form and connected in another, NAT64 addresses wrapping private IPs, robots.txt skipped after redirects | The internal network and site rules | 2026.10.24 |
Filesystem is the server most likely to be copied into real agents, since reading and writing files is the first thing people want a coding or document agent to do. Its four fixes all concern the same promise: the agent works inside the directories you configured and nowhere else. One is a race in which a parent directory swapped for a symbolic link could send a write outside them. The maintainers note that this fix is only partly effective on Windows and the advisory describes how to configure around what remains. Another was a check that stripped a trailing quote or space, so a sibling folder with a similar name passed as allowed.
Everything is a test server that exercises every MCP feature, which is why it has a tool that dumps environment variables. The problem was not that tool; it was that the HTTP transports bound to all network interfaces, accepted any origin and required no authentication. The default stdio transport was not affected. The advisory’s advice generalizes well beyond this package: do not run HTTP transports with real credentials in the environment.
Fetch retrieves web pages for an agent, which makes it a classic server-side request forgery risk: the agent asks for a URL, and the server reaches somewhere the agent should not. Two of its fixes close ways to reach internal addresses by making the address that was checked differ from the address that was connected to.
The upgrade path has a trap
The TypeScript servers moved from date-based versions (such as 2025.9.24) to semantic versions at 1.0.0. Package managers rank 2.0.1 below every 2025.x and 2026.x version, so a team on a date version will not be offered the fix. It has to install 2.0.1 explicitly. The fetch server, published on PyPI, is fixed in 2026.10.24.
That trap is worth a search across repositories, developer machines and agent images this week, because reference servers have a way of ending up in production. They are documented, easy to start, and often the first thing a prototype uses.
Where the boundary of an agent actually lives
We wrote that MCP standardizes how agents connect to tools but does not govern them, and that a gateway can block the tools an agent calls. This release adds the layer underneath: even an allowed tool call is only as safe as the server that executes it. An agent permitted to write to /data/reports relies on the filesystem server to make that true. An agent permitted to fetch public pages relies on the fetch server to refuse internal addresses.
For teams running MCP in production, three practical questions follow:
- Which MCP servers do we run, at which versions, and who updates them? Most organizations can list their agents. Few can list the servers behind them.
- What enforces the boundary if the server fails? A filesystem server inside a container with only the allowed volume mounted, or a fetch server on a network segment with no route to internal addresses, survives the next bug of this kind.
- Which servers listen on a network port? Stdio servers inherit the safety of the process that starts them. HTTP servers need authentication, origin checks and a bind address chosen on purpose.
The agent decides which tool to call. The tool server decides what that call can reach. Security reviews that stop at the first decision are reviewing half the system.