Skip to content
Will Lassalle, Chief Information Officer, JLS Technology USA · October 2026 · Research note
Between January 1 and October 8, 2026, 285 CVEs were published against 149 open-source Model Context Protocol projects: servers, SDKs, frameworks, and gateways. That is the population. The question we asked is simpler than most MCP security research and, as far as we can find, unanswered: after a fix exists, does it reach the places people actually install from?
The short answer is that the fixes exist and the ecosystem mostly moves them, but the places where it fails are the places enterprises trust most: curated catalogs, the official registry, and automated mirror publishers on npm. And the public advisory system that security teams rely on to know a fix is needed runs about two months behind the fix itself.
What we measured, and how
This is a static, metadata-only study. No vulnerable code was executed, no live MCP endpoint was contacted, and no maintainer was contacted before the notices described at the end. Every observation is a version string, a commit comparison, or a registry record retrieved from a public API on October 8, 2026, and every raw response is retained so the findings can be rebuilt offline from the snapshot. The dataset, scripts, and methodology will be published at github.com/jlstechusa/mcp-remediation-propagation-2026 on October 23, 2026, together with the named listings, when the notice window described at the end closes. Collection and analysis scripts were developed with Claude Code; every observation is reproducible from the retained raw responses.
We built the population from the NVD and the GitHub Advisory Database, kept only CVEs whose affected component is an open-source MCP project with a public repository, and excluded host applications where MCP is one feature among many. For each CVE we recorded the affected package, the vulnerable range, the fixed version, and where possible the fix commit. Then we measured four things: how fix releases relate to public advisory dates; what npm, PyPI, the official MCP registry, Smithery, Glama, and the Docker MCP catalog serve today; whether GitHub forks carry the fix; and whether npm packages that re-publish these projects do.
Prior work audited MCP servers for vulnerabilities, most thoroughly a 2026 study that dynamically tested 414 internet-facing servers and filed 68 advisories. Its authors listed remediation reporting as future work. This study is a first pass at that gap.
Finding 1: public advisories trail fixes by about two months
Of the 186 CVEs where both a fix release date and an NVD publication date were observable, 177 were fixed before NVD published the CVE. The median gap is 54 days, fix first. The GitHub Advisory Database is faster but still lags: a median of 32 days after the fix. Only three CVEs in the population were fixed after NVD publication: CVE-2026-0755 (127 days), CVE-2026-7446 (9 days), and CVE-2026-0621 (2 days).
This is not a time-to-fix measurement, because the date a vulnerability was reported to the maintainer is not observable from outside; GitHub returns it as null to the public. It is a measurement of how useful the advisory feeds are as a trigger. For MCP, a security team that waits for NVD is learning about a fix two months after it shipped, which means two months of running a known-vulnerable version if the update process is advisory-driven rather than version-driven.
Finding 2: one in three CVEs has no fixed version at all
93 of the 285 CVEs (33%) have no determinable fixed version: the advisory records no patched release, or the NVD record carries no version range. Nineteen package listings across npm, PyPI, and the official registry serve that unpatched version as the current release. These are not propagation failures. They are maintainers who published a server, received a CVE, and did not ship a fix. They matter here because a registry cannot propagate what was never published, and because anyone installing from the ecosystem’s long tail should assume the long tail is unpatched.
Finding 3: where fixes exist but listings stayed behind
This is the finding the study was built to produce. Where a fixed version exists upstream, we checked what each distribution channel serves today.
Four images in the Docker MCP catalog were built from source commits that predate the upstream security fix, covering 41 CVEs between them. We confirmed this from each image’s own provenance label (the OCI revision in the image config), not from the catalog’s metadata, and the comparison is a commit-ancestry test against the upstream repository. One of the four was last pushed two days before the release that fixed 30 CVEs in that project and has been the catalog’s current image since. Docker builds and pins these images, so the fix is theirs to propagate.
Two entries in the official MCP registry list package versions inside the published vulnerable range while a fixed version exists. Registry entries are published by maintainers, so these are maintainer updates that did not happen.
One npm package has a fixed version recorded in its advisory that was never published to npm; the registry still serves the pre-fix release from early 2025 as current.
One apparent PyPI case turned out to be a data-quality problem in the advisory itself: the GitHub advisory lists a Python ecosystem for a TypeScript project, and the PyPI package with the same name is unrelated. We have submitted a correction. A second advisory points its source location at a repository that no longer exists.
Per our disclosure policy, the affected parties received notice on October 9, 2026, with a 14-day courtesy window because every CVE involved is already public. Named listings will be added to this note on or after October 23, 2026, or earlier where the listing has been updated.
Finding 4: forks are a long tail, and mostly dormant
We enumerated 13,689 forks (the 200 most recently pushed per repository) and tested whether each fork’s default branch contains the upstream fix commit. 4,683 forks (34%) lack at least one fix. 437 of those were pushed to after the fix was released, which is the group that could plausibly be deployed somewhere. Only one of the 437 has ten or more stars. Fork exposure is real but it is thin: thousands of abandoned copies and a handful of active ones, not a hidden population of production deployments.
Finding 5: mirror publishers re-publish vulnerable servers under their own names
Three npm scopes, @iflow-mcp, @mseep, and @fastmcp-me, systematically re-publish other people’s MCP servers under their own package names. Across our population they mirror 24 affected upstream packages as 36 mirror packages. 24 of the 36 serve a version inside the published vulnerable range. Four were republished after the upstream fix and picked it up; the rest have not been touched since before the fix. Nobody installing @iflow-mcp/some-server has a maintainer relationship with the project that received the CVE, and nothing in the mirror’s metadata says so.
For a procurement or supply-chain policy, this is the actionable item: a package whose publisher is not the project’s maintainer is a package whose security updates depend on a third party who has not, in this sample, been keeping up.
What this means if you run MCP servers
Pin by digest and verify provenance. A catalog image tagged latest is a convenience, not an assurance. The OCI revision label in the image config tells you what commit you are running; compare it to the fix commit in the advisory.
Trigger updates on versions, not advisories. If your process waits for NVD, you are two months late by design. Subscribe to the GitHub Advisory Database for the ecosystems you use, and treat a new upstream release as the signal.
Allow-list publishers, not package names. Block the mirror scopes above unless you have a reason to trust them, and in general require that the npm publisher match the project’s maintainer.
Check the official registry entry against the package registry. The MCP registry entry and the npm or PyPI release can disagree; the package registry is the source of truth for what gets installed.
Assume the long tail is unpatched. One third of the CVEs in this population have no fix. If a server has a CVE and no fixed version, the decision is to replace it, not to wait.
Limitations
This is a single snapshot taken on October 8, 2026; listings change. Fork enumeration is capped at 200 per repository and covers direct forks only. The re-publish analysis is npm-only because PyPI has no search API. Smithery and Glama display no served version, so listings there could be confirmed only as present, not as fixed or stale. Where a value could not be observed it is recorded as undeterminable rather than estimated, and the counts above exclude those rows. The full limitations section, every undeterminable value, and the reproduction instructions are in the repository.
Disclosure status
Notices were sent on October 9, 2026 to Docker’s security team (four catalog images), to the maintainers of the two official-registry entries and the one npm package, to the owner of the one active fork with ten or more stars, and to the GitHub Advisory Database for the ecosystem correction. JLS Technology USA’s vulnerability disclosure policy is at jlstech.com/vulnerability-disclosure-policy.
JLS Technology USA, LLC is a managed security services and fractional executive advisory firm. Questions about this research: security@jlstech.com.
