GHSA-95c3-6vvw-4mrq is a medium-severity (CVSS 4.7) Server-Side Request Forgery (SSRF) vulnerability in github.com/modelcontextprotocol/registry. A fix is available for github.com/modelcontextprotocol/registry — see the affected versions and patch details below.
MCP Registry's GitHub OIDC tokens are replayable across registry deployments due to shared audience
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-95c3-6vvw-4mrq.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-95c3-6vvw-4mrq plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 378,567 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
github.com/modelcontextprotocol/registryReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
[SECURITY] registry_001 Vulnerability Report
While analyzing the code logic, an area that may lead to unintended behavior under specific conditions was discovered.
Overview
- Verified Version:
c5c4b9e8890dd5754bee889b2f1417f4fe3b5ce5 - Vulnerability Type: Authentication bypass via cross-registry OIDC token replay
- Affected Location:
cmd/publisher/commands/login.go:67-105,130-135,199-224;cmd/publisher/auth/github-oidc.go:24-38,58-75,108-165;internal/api/handlers/v0/auth/github_oidc.go:75-135,229-277,280-296 - Trigger Scenario: a workflow invokes
mcp-publisher login github-oidc --registry <other-registry>(or equivalent publish flow) and the publisher still requests a GitHub Actions ID token with the shared audiencemcp-registry; any other registry deployment running this code can replay that token to its own/v0/auth/github-oidcendpoint and mint a publish-capable registry JWT for the same GitHub owner namespace.
Root Cause
The client-side and server-side GitHub OIDC flow is bound only to a global audience string, not to the specific registry instance being targeted. On the client side, the publisher always appends audience=mcp-registry when requesting the GitHub Actions ID token, regardless of the selected --registry URL. On the server side, the exchange endpoint validates only that same fixed audience and then derives publish permissions directly from repository_owner. As a result, a token legitimately obtained while interacting with one registry deployment remains acceptable to any other deployment that shares the same code and audience string.
Source-to-Sink Chain
- Source
cmd/publisher/commands/login.go:67-105,130-135,199-224parses the user-controlled--registryflag intoflags.RegistryURL, creates aGitHubOIDCProvider, and callsauthProvider.GetToken(ctx)for the chosen authentication method. - Propagation
cmd/publisher/auth/github-oidc.go:24-38obtains an OIDC token and immediately exchanges it against the selected registry URL.cmd/publisher/auth/github-oidc.go:58-75buildsexchangeURL := o.registryURL + "/v0/auth/github-oidc"and posts the GitHub token to whichever registry instance was selected.cmd/publisher/auth/github-oidc.go:108-165constructsfullURL := requestURL + "&audience=mcp-registry"and therefore requests the same audience for every registry deployment. - Sink
internal/api/handlers/v0/auth/github_oidc.go:75-135validates only the shared audience value passed intoValidateToken.internal/api/handlers/v0/auth/github_oidc.go:254-277callsh.validator.ValidateToken(ctx, oidcToken, "mcp-registry")and, on success, signs a new registry JWT.internal/api/handlers/v0/auth/github_oidc.go:280-296convertsclaims.RepositoryOwnerinto the publish permission patternio.github.<owner>/*, which is then embedded into the new registry JWT.
Exploitation Preconditions
- The victim uses the GitHub Actions OIDC publishing path.
- The victim workflow targets another registry deployment first, such as staging, self-hosted infrastructure, or an attacker-controlled registry URL.
- The receiving registry deployment can observe the posted OIDC token and replay it before expiry to another registry deployment running the same shared audience configuration.
Risk
This breaks deployment isolation between registry instances. A token issued for one registry interaction can be replayed across trust boundaries, allowing one deployment to impersonate the same GitHub owner identity on another deployment.
Impact
An attacker-controlled or compromised registry deployment can mint a valid registry JWT on another deployment and inherit publish permissions for the victim GitHub owner namespace. In practical terms, this enables unauthorized publication or update actions for names such as io.github.<owner>/* on the victim registry instance.
Remediation
- Replace the shared audience string with a registry-specific audience, such as a deployment-specific client ID or origin-derived identifier.
- Ensure the publisher requests the audience that matches the exact registry instance it is targeting, and ensure the server validates that same instance-specific value.
- Consider binding the exchange to additional deployment-specific claims so that a token captured by one registry cannot be replayed on another.
- Add regression tests that cover cross-deployment replay attempts between different registry URLs.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/modelcontextprotocol/registry | all versions | 1.7.6go get github.com/modelcontextprotocol/registry@v1.7.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/modelcontextprotocol/registry, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/modelcontextprotocol/registry to 1.7.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-95c3-6vvw-4mrq is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-95c3-6vvw-4mrq can be triaged on real exposure rather than presence alone.
Tailored to GHSA-95c3-6vvw-4mrq. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-95c3-6vvw-4mrq in your dependencies?
O3 Security finds GHSA-95c3-6vvw-4mrq across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.