Skip to content
T threat.cafe

· Priya Venkatraman (editorial persona) · Original research and datasets · on threat.cafe

35 MCP server advisories in one month: what October says about trusting even the reference servers

Official MCP servers need patch tracking too. In October 2026, TestedMCP counted 35 security advisories across 10 MCP server listings, and 8 of them hit the official reference servers: Filesystem, Fetch and Everything. Only 1 of the 35 had a CVE, so your scanner probably saw none of the reference-server fixes. Popular and official do not mean finished. Track each MCP server you run like any other dependency, and check that opt-in fixes are switched on.

The question you are actually asking

The question most teams ask about MCP servers is whether the official ones can be trusted as installed. An MCP server is a small program your agent talks to. It holds credentials, reads files and makes web requests on the model's behalf. If you installed the reference Filesystem server from a README in the spring, you want to know one thing: is that copy still fine?

The October 2026 data gives you a plain answer. Probably not without an upgrade. The 4 Filesystem advisories published on 25 October were all fixed in @modelcontextprotocol/[email protected]. Any earlier copy in the affected range still has them.

The catch is that "official" describes who maintains a server, not how finished it is. The reference servers are teaching code that many people run in production. That is a reasonable choice, as long as you treat them like the dependency they are.

What the October numbers say

The October 2026 count comes from TestedMCP's October page, last checked 27 October. It used primary sources: the GitHub advisory API, OSV.dev, NVD and project changelogs. It ran no exploits. A GHSA is a GitHub Security Advisory, the record a maintainer publishes on GitHub. "In range" means the version TestedMCP had tested was still affected.

The threat.cafe October 2026 MCP Advisory Tally below restates TestedMCP's counts. The bug-class split is threat.cafe's own grouping.

The threat.cafe October 2026 MCP Advisory Tally
Source counts: TestedMCP, checked 2026-10-27. Bug classes: threat.cafe grouping.

By listing (n = 35 advisories, 10 listings)      Advisories  In range for tested version
-----------------------------------------------  ----------  ---------------------------
GitLab (zereight)                                12          4
Excel (haris-musa)                               8           0
Filesystem (reference)                           4           0
Fetch (reference)                                3           0
Chrome DevTools MCP                              2           0
Basic Memory                                     2           2
Everything (reference)                           1           0
Kubernetes (Flux159)                             1           0
Serena                                           1           0
Browser Tools (AgentDesk)                        1           0
Total                                            35          6 of 35
With a CVE                                       1 of 35 (CVE-2026-104776, Kubernetes)

By bug class (n = 35; each advisory placed once, by main effect)
-----------------------------------------------  -----
Path, symlink and file confinement               9   Filesystem 4, Chrome DevTools, Excel (UNC paths),
                                                     Kubernetes, Basic Memory, GitLab (file overwrite)
OAuth, session and origin binding                7   GitLab 5, Basic Memory (DNS rebinding),
                                                     Everything (cross-origin env exfiltration)
SSRF and egress guards                           6   Fetch 3, Chrome DevTools, Browser Tools,
                                                     GitLab (credentials sent to .npmrc registry)
Authorisation and allowlist scope                5   GitLab (project allowlist, hidden toolsets)
Content validation (formula/import checks)       4   Excel
Resource exhaustion                              3   Excel (zip bomb, VBA parse, full-parse path)
Deserialisation                                  1   Serena (pickle cache, fixed 2.0.0)

Six of 35 were in range for the tested version. The other 29 were already fixed in what TestedMCP tested. That sounds reassuring, and it is, for anyone running those tested versions. Your laptop may run something older.

The mechanism, layer by layer

Most October 2026 advisories describe a guard that existed and failed at an edge. A guard is a check that sits between a tool call and the real world, such as "only read files inside this folder". Three layers show how that goes wrong.

Layer 1, the path check. The Filesystem server checks that a path stays inside the folders you allowed. GHSA-4gxg-m5jx-9j57, credited to 0xCoDSnet, rated moderate (5.3), shows the gap. On case-insensitive disks like macOS APFS and Windows NTFS, a path with different letter case could pass the symlink check. If an allowed folder held a symlink pointing outside, files could be created outside the allowed folders. Existing outside files could not be read or overwritten this way.

Layer 2, the network check. The Fetch server gained a private-address guard in 2026.10.10. Its job is to stop the fetch tool reaching your internal network. GHSA-v38p-wf49-hx2j, credited to dizconnectz, found the guard and the HTTP client resolved different forms of an internationalised hostname. In default configuration, fetch could then reach loopback, private-network or cloud-metadata endpoints. That needed the model to fetch an attacker-controlled URL first. The new guard needed its own fix within 2 weeks, in 2026.10.24.

Layer 3, the setting you have to turn on. Some fixes ship disabled. The Python mcp SDK advisory GHSA-w4fh-qvv9-3v23 says: "Upgrading alone changes nothing." Versions 1.30.0 and 2.2.0 add a validate_token_resource setting, and it is off by default.

A worked example with real numbers

Picture a team running 3 reference servers on 20 developer laptops in October 2026. The reference-server fixes landed as [email protected], [email protected] and mcp-server-fetch==2026.10.24. Eight advisories, published on 25 October UTC, cover those 3 servers. With 1 CVE in the whole set of 35, and none on the reference servers, a CVE scanner shows you nothing for any of the 8.

Now the version trap. The Filesystem advisory notes that users on date-based versions, 2025.x or 2026.x, must install 2.0.1 explicitly. Package managers won't offer it as an upgrade, because 2026.8.31 looks newer than 2.0.1. So npm update on all 20 laptops can leave every one of them affected. You only catch that by comparing your version against the advisory's affected range.

Beyond the 35, TestedMCP lists 9 MCP Inspector advisories, published 21 October with no CVEs as of 26 October. One is GHSA-4fc4-wcmh-4g86, a critical (9.6) issue credited to bhavya32 and fixed in 1.0.3. If your team uses Inspector to debug servers, add it to the same list.

The strongest objection, and why it does not hold

The best case against this post goes like this. Volume reflects scrutiny, not weakness. GitLab's 12 advisories more likely show active researchers and a responsive maintainer than a weak project. Most of the 35 are rated low or medium, and 29 of 35 were already fixed in the tested versions. On that view, a monthly count mostly measures how open a project is.

Much of that is right, and the conclusion still holds. A responsive maintainer only helps you if you pick up the fix. The Filesystem version trap and the off-by-default SDK setting both mean a fix can exist while your install stays exposed. A quiet advisory page tells you little on its own, in either direction.

What to tell the people who sign off

The case for patch-tracking MCP servers fits on four lines:

  • Finance: the cost is owner time for a weekly version check, not a new product.
  • Security lead: MCP servers hold tokens and touch files and networks. The October 2026 classes most often involved paths (9 of 35) and OAuth or session binding (7 of 35).
  • Legal and compliance: record GHSA IDs and installed versions as patch evidence, since 34 of 35 had no CVE.
  • Operations: pinning means explicit upgrades. Rollback is a pin change.

How to track this yourself

The tracking routine below works for any MCP server, SDK or Inspector you run:

  1. Watch advisories per repository. Watch each server's GitHub repository with security alerts on. Include modelcontextprotocol/servers, modelcontextprotocol/inspector, modelcontextprotocol/python-sdk and the TypeScript SDK.
  2. Check versions where they run. Use npm ls @modelcontextprotocol/server-filesystem, or npm ls -g for global installs. For Python, use pip show mcp-server-fetch and pip show mcp. Unpinned npx and uvx launch lines may resolve differently on each machine.
  3. Compare against affected ranges, not "latest". The Filesystem date-based versions show why.
  4. Pin and re-verify on a cadence. Weekly suits servers with file or network access. See our post "Approved last month, malicious today: a re-verification cadence".
  5. Python mcp 1.30.0 or 2.2.0: set validate_token_resource=True and resource_server_url in AuthSettings, unless your token verifier already checks audience.
  6. MCP SDK and FastMCP clients: configure the expected OAuth issuer, and clear or re-bind stored credentials, per TestedMCP's summary of the issuer-binding advisories.
  7. Claude Code in CI: use --bare with --mcp-config, as TestedMCP suggests.
  8. Narrow what each server can reach. Path and egress bugs hurt less when allowed folders are small and outbound traffic is allowlisted. See our post "Egress allowlisting for coding agents and CI runners".

The decision tree below is the short version to paste into your team channel.

threat.cafe MCP server patch check (October 2026)

Is the server on your machines pinned to an exact version?
  No  -> pin it, then continue.
  Yes -> continue.
Does a GHSA list your version in its affected range?
  Yes -> upgrade to the fixed version. Date-based version? Install the fix explicitly.
  No  -> continue.
Does the fix need a setting (e.g. validate_token_resource, OAuth issuer)?
  Yes -> turn it on and test. Upgrade alone is not enough.
  No  -> record "no known bad" for this version, with the date checked.
No advisory feed for this repo yet?
  -> verdict is "unknown". Add a watch before approving.
Re-run weekly for servers with file or network access.

Where this would be wrong

The argument for tracking MCP servers like dependencies has limits you should know. It would be overstated if most teams already pin MCP servers and scan the GitHub advisory database; then October 2026 is routine patching. TestedMCP did not test the Inspector, SDK or reference-server fixes, so those rest on vendor advisories. Its page also dates the reference-server advisories 25 October UTC in the text and 24 October in its tables. The 35 excludes servers TestedMCP does not list and 10 remote-only listings it could not check. Treat 35 as a floor for the ecosystem, not a total. Whether CVEs arrive later is unknown.

threat.cafe plans to publish a monthly MCP advisory digest, built on roundups like TestedMCP's and the primary advisories. Meanwhile, check any MCP server name against the threat.cafe board.

Volatility: VOLATILE (event-triggered review). Review when TestedMCP publishes its November 2026 roundup, or when a CVE is assigned to any reference-server advisory.

Sources

#mcp-servers #ghsa #reference-servers #patch-tracking #dataset

All posts