Evidence used
- No CISA KEV confirmation is currently recorded.
- A structured source references public exploit or proof-of-concept material.
- EPSS is 0.25% for the current model date.
BlackTreeCVE Intelligencemodelcontextprotocol · registry
Official source article: GitHub GHSA-2V5F-5R6W-P67R ↗. Check the applicable product and release in the original source.
Low technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance.
These OSV and GitHub advisory ranges apply only to the named package and ecosystem. A listed fixed version is not a universal product patch or proof that an update is installed.
| Ecosystem and package | Affected range | First fixed version | Evidence |
|---|---|---|---|
| Gogithub.com/modelcontextprotocol/registry | SEMVER: introduced 0; fixed 1.7.9 | 1.7.9 | OSV record ↗aggregator derived · 10 Sep 2026 |
| gogithub.com/modelcontextprotocol/registry | < 1.7.9 | 1.7.9 | GitHub advisory ↗upstream repository advisory · 19 May 2026 |
Low technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance.
Fix not verifiedThe MCP Registry provides MCP clients with a list of MCP servers, like an app store for MCP servers. Prior to 1.7.9, OCI ownership validation skips label-match check when upstream OCI registry returns HTTP 429, letting any authenticated publisher bind their io.github.<user>/* namespace to OCI images they do not control. internal/validators/registries/oci.go:104-119 fails open on http.StatusTooManyRequests: when the registry's anonymous fetch to the upstream OCI registry is rate-limited, ValidateOCI returns nil and the publish is accepted without ever running the io.modelcontextprotocol.server.name label-match check at lines 122-141. That label check is the only cross-system ownership proof the registry applies to OCI packages — every other registry type (NPM, PyPI, NuGet, MCPB) treats a non-200 upstream response as a hard error. This vulnerability is fixed in 1.7.9.
The MCP Registry provides MCP clients with a list of MCP servers, like an app store for MCP servers. Prior to 1.7.9, OCI ownership validation skips label-match check when upstream OCI registry returns HTTP 429, letting any authenticated publisher bind their io.github.<user>/* namespace to OCI images they do not control. internal/validators/registries/oci.go:104-119 fails open on http.StatusTooManyRequests: when the registry's anonymous fetch to the upstream OCI registry is rate-limited, ValidateOCI returns nil and the publish is accepted without ever running the io.modelcontextprotocol.server.name label-match check at lines 122-141. That label check is the only cross-system ownership proof the registry applies to OCI packages — every other registry type (NPM, PyPI, NuGet, MCPB) treats a non-200 upstream response as a hard error. This vulnerability is fixed in 1.7.9.
When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
The MCP Registry provides MCP clients with a list of MCP servers, like an app store for MCP servers. Prior to 1.7.9, OCI ownership validation skips label-match check when upstream OCI registry returns HTTP 429, letting any authenticated publisher bind their io.github.<user>/* namespace to OCI images they do not control. internal/validators/registries/oci.go:104-119 fails open on http.StatusTooManyRequests: when the registry's anonymous fetch to the upstream OCI registry is rate-limited, ValidateOCI returns nil and the publish is accepted without ever running the io.modelcontextprotocol.server.name label-match check at lines 122-141. That label check is the only cross-system ownership proof the registry applies to OCI packages — every other registry type (NPM, PyPI, NuGet, MCPB) treats a non-200 upstream response as a hard error. This vulnerability is fixed in 1.7.9.
When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
An attacker operating through a network path may attempt exploitation with low privileges. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
CISA Vulnrichment records proof-of-concept exploitation in its SSVC data. BlackTree has not independently executed or validated exploit material.
CWE-636: Not Failing Securely ('Failing Open'). When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:NCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 14 May 2026 · Last source change 16 May 2026, 01:06 UTC · CWE-636 · Not Failing Securely ('Failing Open')
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.