MCP Registry OIDC Token Replay: Shared Audience Lets Rogue Registries Inherit Publish Rights (CVE-2026-44428)
The official Model Context Protocol registry used a shared OIDC audience across all registry deployments. Any attacker-controlled or compromised registry instance could take a GitHub OIDC token minted for itself and replay it against a different registry deployment, inheriting that deployment's publish permissions. The flaw sits at the top of the MCP supply chain, in the infrastructure that distributes MCP servers to clients at scale.
What happened
GitHub OIDC tokens are short-lived identity assertions minted per workflow run. They are audience-bound: a token minted for registry A should not be accepted by registry B. When all registry deployments share a single audience value, that binding disappears. Any deployment can present another's token as its own.
CVE-2026-44428 is precisely that failure in modelcontextprotocol/registry. Prior to version 1.7.6, the registry's GitHub OIDC integration did not include per-instance audience values in token validation. An attacker-controlled registry deployment could obtain a valid OIDC token through its own legitimate publish workflow and replay it against another registry instance, inheriting the publish rights of that target deployment.
The consequence is a supply chain injection path into the official MCP package registry itself. An attacker who can publish to the registry can distribute malicious MCP servers to any client that fetches packages from it. The fix in 1.7.6 ties the OIDC audience to the specific registry deployment, breaking cross-instance replay.
The PolicyLayer angle
A flaw in the registry that distributes MCP servers is categorically different from a flaw in any single MCP server. Every client that fetches packages from a compromised registry is a potential victim, regardless of whether those clients have any other security controls in place.
The agent-side controls that reduce risk from registry-level supply chain compromise: deny-by-default on unreviewed MCP servers, package identity pinning (specific version hashes rather than semver ranges), and separate approval gates before any newly-fetched MCP server is allowed to register tools with an agent. None of these depend on the registry being uncompromised, which is the point. Registries can be attacked; the question is whether a malicious package delivered through a registry can reach an agent's tool execution surface without any out-of-band approval.
CVE-2026-44428 is the class of risk that package pinning and provenance verification exist to address. An MCP client that only installs servers from pinned, reviewed versions cannot be silently updated to a malicious version even if the registry is fully compromised.
Mitigations
Upgrade the MCP Registry to version 1.7.6 or later. For self-hosted registry deployments, verify that per-deployment OIDC audience values are configured and that no cross-deployment token replay is possible. Clients consuming packages from MCP registries should pin to specific version hashes rather than floating semver ranges, and require explicit review before updating to a new server version.
FAQs
It affects any deployment of modelcontextprotocol/registry prior to 1.7.6 that uses GitHub OIDC for publisher authentication. Self-hosted instances are at higher risk because the shared-audience issue directly enables a rogue instance to inherit publish rights on other deployments. The public MCP Registry should be assumed to have applied the fix.
Because the registry sits upstream of every client that consumes packages from it. A single server flaw affects users of that server. A registry flaw affecting publish authorisation means any package in the registry could be replaced with a malicious version. The attack surface is every MCP client that auto-updates or fetches new servers without version pinning.