MCP Registry OIDC Flaw CVE-2026-44428 Lets Attackers Hijack GitHub

Executive Summary

The Model Context Protocol (MCP) Registry, a directory that lets MCP clients discover and install MCP servers (functioning similarly to an app store for these AI-agent components), contained a vulnerability in its GitHub OpenID Connect (OIDC) authentication flow prior to version 1.7.6. Tracked as CVE-2026-44428 with a CVSS score of 4.7, the flaw allows an attacker who obtains a valid GitHub OIDC token from one registry instance to replay that token against another instance, because the token's audience claim is bound only to a global string (mcp-registry) rather than to the specific registry instance being targeted. This cross-instance token reuse could enable an attacker to publish malicious MCP servers under a victim's GitHub identity, posing a supply-chain risk to the MCP ecosystem. The maintainers patched the issue in version 1.7.6, released on 2026-05-14, by binding the OIDC audience to the specific registry instance's identifier.

Technical Analysis

The MCP Registry, hosted at github.com/modelcontextprotocol/registry, provides a centralized listing of MCP servers. To allow automated publishing via GitHub Actions, the registry implements an OIDC-based authentication flow where a publisher's GitHub Actions workflow requests an ID token from GitHub's OIDC provider, which is then presented to the registry for verification.

According to the advisory published by the registry maintainers, the vulnerability resides in how the OIDC audience claim is validated. On the client side (the GitHub Actions workflow), the publisher always appends audience=mcp-registry when requesting the ID token from https://token.actions.githubusercontent.com. On the server side, the registry accepts any token whose audience matches the string mcp-registry, without verifying that the token was issued for the specific registry instance it is being presented to.

This means that if an attacker compromises or intercepts a valid ID token generated for any MCP Registry instance (including a private or test instance), they can replay that token against a different registry instance — for example, the public production registry at registry.mcp.io. The token's signature and expiration remain valid; only the audience binding is insufficiently scoped.

An attacker who successfully replays a token can then perform actions authorized by that token on the target registry instance. In the context of the MCP Registry, the primary risk is unauthorized server publishing: the attacker could submit a new MCP server listing under the victim publisher's GitHub identity, or modify an existing listing. Since MCP servers can execute arbitrary code on the client side (they are essentially plugins that an MCP host runs), a malicious server listing could deliver malware, exfiltrate data, or perform other harmful actions to any user who installs it.

The flaw is analogous to a cross-site request forgery (CSRF) against an OIDC token, but operates at the protocol level rather than the HTTP level. The maintainers note that the attack requires the attacker to first obtain a valid ID token from some registry instance — a non-trivial prerequisite, but one that could be achieved through a compromised CI/CD pipeline, a misconfigured private registry, or a social engineering attack that tricks a legitimate publisher into running a malicious workflow.

The CVSS score of 4.7 (Medium) reflects the relatively high attack complexity and the requirement for the attacker to already possess a valid token. However, the supply-chain implications — a single malicious server could affect many downstream users — elevate the practical severity beyond the numerical score.

Mitigations & Recommendations

All MCP Registry operators and users should upgrade to version 1.7.6 or later immediately. The patched version changes the OIDC audience validation to require an instance-specific identifier, preventing token reuse across different registry instances.

For organizations that self-host the MCP Registry, the maintainers recommend reviewing any existing OIDC tokens that may have been issued prior to the upgrade, as those tokens remain valid until they expire. Rotating GitHub Actions OIDC tokens by invalidating existing workflow runs or updating the id-token: write permission scope can reduce the window of exposure.

Defenders should also monitor for unusual publishing activity in their MCP Registry instances — specifically, server listings that appear under a known publisher's identity but were created at unexpected times or from unexpected IP ranges. Since the attack requires the attacker to have a valid token, any unauthorized publishing event would indicate a broader compromise of the victim's CI/CD pipeline.