MCP Server Suite v2.2.0 Released: CA Certificate Update and Multiple Security Hardening Measures

The official Model Context Protocol (MCP) server suite has reached version v2.2.0. The main thrust of this update is not new features but a security response centered on the CA certificate trust chain, along with fixes for long-standing edge cases across multiple servers including filesystem, web fetching, and Git operations. For developers running these MCP servers in production, this is an upgrade that deserves serious attention.

A Chain Reaction Triggered by a CA Private Key Leak

The story began on October 20, 2026: certificate authority eMudhra disclosed that the private keys of eight of its intermediate CA certificates could be recovered from public certificates. This means any trust chain relying on those root certificates could be abused. The next day, Node.js released security versions that updated the built-in CA certificate bundle and also fixed several high-severity runtime CVEs. On October 23, Python's certifi package released version 2026.10.23, removing eMudhra's emSign Root CA - C1 and emSign ECC Root CA - C3 root certificates.

The MCP server suite followed up with v2.2.0 on October 28, with the core action being to place each server on the updated trust foundation. The release notes detail the exposure surface for each server type: TypeScript servers do not carry CA certificates themselves and rely entirely on the Node.js runtime they run on for certificate validation; among them, only server-everything makes outbound HTTPS requests (via the gzip-file-as-resource tool), while server-filesystem, server-memory, and server-sequential-thinking establish no network connections at all. On the Python side, mcp-server-fetch uses httpx and performs HTTPS validation with the certifi package, resolving to the current version of certifi when installed from PyPI; the repository's Dockerfile also advanced its lock file to certifi 2026.10.23 in this release. mcp-server-git and mcp-server-time likewise make no network connections.

This "categorized by exposure surface" approach is noteworthy: rather than broadly requiring everyone to upgrade, it explicitly identifies which components carry actual risk and which are only theoretically related.

Intermediate CAs and the Trust Chain: In the PKI system, the root CA sits at the top of the trust chain, and the root certificate list built into browsers and runtimes is the ultimate anchor of trust. Intermediate CAs are issued by root CAs and are used to actually issue end-entity certificates (such as website certificates). If an intermediate CA's private key is recovered or leaked, an attacker can use it to issue certificates for any domain recognized by the trust chain without compromising the root CA. The key aspect of the eMudhra incident is that "private keys could be recovered from public certificates"—this typically suggests insufficient entropy or parameter generation flaws at issuance time, a more insidious failure mode than a simple private key leak. For clients, the only stopgap is to remove the corresponding root certificate from the trust store, at the cost of simultaneously invalidating all legitimate sites that depend on that root. This is why the update must be done at the trust store layer, such as Node.js and certifi, rather than patching individual applications.

The Difference Between certifi and System Certificate Stores: In the Python ecosystem, certifi is a standalone package that bundles Mozilla's CA certificates, and libraries like httpx and requests use it by default for TLS validation rather than the operating system certificate store. Therefore, the trust root update cadence for Python services is determined by certifi's releases and is unrelated to the system's update-ca-certificates. This also explains why virtual environments "freeze" old trust roots: the certifi version resolved at environment creation time is written into the lock, and subsequent updates do not automatically follow upstream.

Runtime Upgrade: TypeScript Server Users Need to Check Their Own Setups

For users running TypeScript servers via npm (npx or global install), the release notes provide a clear requirement: please run Node.js 24.22.1 or 26.12.1 and above, and confirm with node --version. The reason is that these packages' engines field accepts any Node.js 24, so npm will not warn about an outdated runtime version—meaning an unpatched Node.js can continue running silently.

For users running mcp-server-fetch in existing environments, the situation is similar: environments created before October 23 will retain the old certifi, and need to be refreshed with uvx --refresh mcp-server-fetch or updated with pip install -U certifi.

This "dependency provided by the user's environment" design is common in MCP servers; it reduces release package size but transfers patch responsibility to the user. The v2.2.0 notes are effectively a reminder: security updates will not automatically reach your machine.

SemVer Ranges and the Limitations of the engines Field: The engines field of an npm package only declares a compatibility range and by default does not block installation unless engine-strict is enabled. When a package declares node: ">=24", any patch version of 24.x satisfies the condition, including older patch versions that have not yet fixed the CA bundle or runtime CVEs. This is why the release notes require "24.22.1 or 26.12.1 and above" but npm cannot automatically enforce it: version constraints express API compatibility, not security baselines. In practice, you can use npm config set engine-strict true, explicitly assert node --version in CI, or pin patch versions with .nvmrc/volta to turn the security baseline from a "recommendation" into a "gate."

Fix List for Each Server

Setting the certificate topic aside, the number of fixes in this release is considerable, mostly concentrated on input boundaries and exception paths.

server-everything 2.1.0

This package fixed the aggregation logic for elicitation requests over the form's own fields; gzip-file-as-resource now correctly fails when receiving HTTP error responses and rejects non-public addresses at every hop; get-env masks credential-like values by default; corrupted iCCP data chunks in get-tiny-image's PNG were removed, along with corrections to several misleading names and JSDoc header comments in get-resource-links.

server-filesystem 2.1.0

The filesystem server has the densest set of fixes: case variants of allowed directories are now accepted after filesystem confirmation; tail no longer counts a trailing newline as a line, and head normalizes CRLF lines to LF; get_file_info now reports hard link counts and includes hard link documentation; realpath and readdir waits as well as recursive traversal now have bounds; a failed realpath is retried once to avoid losing the root directory; both the declared form and the realpath form of client Roots are accepted; moving files across filesystems goes through a copy path on EXDEV; identity comparison for overwrites now uses BigInt stats with a Windows no-device-number fallback; the 100,000-entry traversal test now has an explicit timeout.

EXDEV and Cross-Filesystem Moves: POSIX rename(2) can only complete atomically within the same filesystem; across mount points (such as moving from /tmp's tmpfs to disk, or across Docker volumes) it returns EXDEV. The correct approach is to fall back to "copy to a temporary file at the destination + fsync + rename + delete the source," ensuring at least that no half-written files are produced when atomicity cannot be guaranteed. Similarly, realpath may fail transiently when symlinks or mount points change, and retrying once is a common mitigation for races; comparing identity with the BigInt version of stat avoids misjudgments caused by inode and device numbers being truncated at 32-bit precision.

server-memory 2.0.1

Stored records now retain unmodeled fields across multiple writes; if memory.json migration fails, startup stops rather than continuing with an inconsistent state.

mcp-server-fetch 2026.10.28

Autonomous fetching is refused when robots.txt returns 5xx; IPv4-compatible IPv6 addresses (::/96) are rejected; under beautifulsoup4 4.13, pages with empty trees are reported as unable to simplify; responses without a Content-Type are treated as HTML only when the body is actually HTML; a new --no-readability-js option lets content extraction bypass Node.js; pages are decoded according to the charset declared in the HTML; readabilipy 0.3.0 is required so non-cp1252 pages can be extracted on Windows; server-side rendered content hidden by hydration is restored; the beautifulsoup4 dependency is declared, and missing Content-Type is indicated in the raw prefix.

SSRF Protection and Address Classification: Fetching servers are natural entry points for SSRF. Checking only literal IPs is insufficient because IPv4-compatible IPv6 addresses (::/96, such as ::127.0.0.1) can bypass filters based on IPv4 strings; additionally, decimal/octal notations, DNS rebinding, and re-checking at "every hop" of HTTP redirects must be handled—validating only on the first request allows an attacker to redirect to an internal network via a 302. The release notes' "rejects non-public addresses at every hop" is exactly the implementation of this principle. Refusing autonomous fetching when robots.txt returns 5xx is a fail-closed policy: a server error does not mean fetching is allowed, and it is better to give up than to overstep.

mcp-server-git 2026.10.28

The documentation explicitly states: without --repository, all reachable repositories are in scope; branches are created on a detached HEAD and from a commit-ish base; non-ASCII paths are printed as-is, and undecodable diff bytes are replaced; GHSA-w766-5x43-whvw is fixed.

mcp-server-time 2026.10.28

LOCAL_TIMEZONE in the Docker image is now expanded at runtime.

Community Contributions and Release Process Adjustments

The release notes devote an entire section to thanking the community. @ShieldPi1 reported GHSA-w766-5x43-whvw, @alemuenchen reported the recursive traversal boundary issue (#4162), and @DrDexter6000 and @morozow reported issues related to SSR content fallback (#3878). Numerous contributors' PRs were closed, the changes were rebuilt by maintainers, and attribution was given on the corresponding issues—this stems from the repository's "use issues, not PRs" policy.

There were also CI changes: superseded dispatched runs no longer publish pending status; Claude workflows only start for trusted authors; a new alert sweep tracks advisories that do not yet have patched versions.

For teams using MCP servers, the v2.2.0 upgrade checklist can be summarized as: confirm the Node.js version, refresh certifi, and watch for behavior changes in filesystem and fetch under exceptional inputs. The certificate incident itself has passed, but the architecture of relying on user environments to provide trust roots means the next similar disclosure will propagate to every deployment point in the same way.

One-line Summary

MCP Server Suite v2.2.0 responds to the CA private key leak incident and comprehensively fixes edge cases across multiple servers.

Paragraph Summary

The official MCP server suite has released v2.2.0, driven primarily by the eMudhra incident in which the private keys of eight intermediate CAs could be recovered: Node.js and certifi updated their trust stores in succession, and the suite followed up, categorizing risks by each server's actual network exposure. TypeScript server users must verify their Node.js version themselves, and existing fetch environments need a certifi refresh to remove the problematic root certificate. The release also fixes numerous input boundary and exception path issues in servers including filesystem, fetch, memory, git, and time, covering cross-filesystem moves, charset decoding, robots.txt 5xx handling, and the GHSA-w766-5x43-whvw security advisory. The overall signal is clear: security updates will not automatically reach deployment points that rely on user environments to provide trust roots.