GHSA-rqv2-m695-f8j4 is a medium-severity (CVSS 5.4) vulnerability in github.com/modelcontextprotocol/registry. O3 Security confirms whether GHSA-rqv2-m695-f8j4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
MCP Registry vulnerable to stored XSS in catalogue UI via attribute-quote breakout in publisher-controlled `websiteUrl`
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
Summary
The public catalogue UI served at GET / (file internal/api/handlers/v0/ui_index.html) is vulnerable to stored cross-site scripting via the server.websiteUrl field of any published server.json. Server-side validation in internal/validators/validators.go (validateWebsiteURL) only checks that the URL parses, is absolute, and uses the https scheme; it does not reject quote characters. Client-side, the value is interpolated into a double-quoted href attribute via innerHTML, using a homegrown escapeHtml helper that performs the standard textContent → innerHTML round-trip. Per the HTML serialisation algorithm, that round-trip encodes only &, <, > and U+00A0 inside text nodes — it does not encode " or '. A literal " in websiteUrl therefore breaks out of the href attribute, allowing arbitrary on* event handlers to be appended to the same <a> element. The Content-Security-Policy on / is script-src 'self' 'unsafe-inline' https://cdn.tailwindcss.com, so the injected event handlers execute.
Any user able to obtain a publish token (e.g. via POST /v0/auth/github-at with their own GitHub account, or POST /v0/auth/none on a deployment that has anonymous auth enabled) can plant a poisoned record visible to every visitor of the registry homepage.
Affected component
- Validator:
internal/validators/validators.go—validateWebsiteURL(lines 153–199) - Sink:
internal/api/handlers/v0/ui_index.html—toggleDetails(card, item)at line 432, thehrefattribute built aroundescapeHtml(server.websiteUrl) - Helper:
escapeHtmldefined atinternal/api/handlers/v0/ui_index.htmllines 494–498
Proof of concept
-
Obtain a Registry JWT for any namespace you control (a GitHub OAuth exchange against a throwaway account suffices):
TOKEN=$(curl -sS -X POST https://registry.modelcontextprotocol.io/v0/auth/github-at \ -H 'Content-Type: application/json' \ -d '{"github_token":"<gh-pat>"}' | jq -r .registry_token) -
Publish a server with a poisoned
websiteUrl. The literal"is preserved end-to-end:curl -sS -X POST https://registry.modelcontextprotocol.io/v0/publish \ -H "Authorization: Bearer $TOKEN" \ -H 'Content-Type: application/json' \ --data-binary @- <<'EOF' { "$schema": "https://static.modelcontextprotocol.io/schemas/2025-09-29/server.schema.json", "name": "io.github.<your-account>/xss-poc", "version": "0.0.1", "description": "hover the website link", "websiteUrl": "https://example.com/\"onmouseover=alert(document.domain)//" } EOF -
Visit
https://registry.modelcontextprotocol.io/, search forxss-poc, click the card to expand it, then hover the Website link in the details panel. The injectedonmouseoverfires andalert(document.domain)runs on theregistry.modelcontextprotocol.ioorigin.
Why server-side validation does not catch this
Go's net/url.Parse accepts literal " in the path component:
input="https://example.com/\"onmouseover=alert(1)//" IsAbs=true Scheme="https" Path="/\"onmouseover=alert(1)//"
Neither the Huma format:"uri" annotation nor validateWebsiteURL's scheme/IsAbs triplet rejects this string. The architecture's existing protection — repository.url is regex-locked to ^https?://(www\.)?github\.com/[\w.-]+/[\w.-]+/?$ and therefore cannot contain quotes — does not extend to websiteUrl, which has no allowlist.
Why client-side escapeHtml does not catch this
function escapeHtml(text) {
const div = document.createElement('div');
div.textContent = text;
return div.innerHTML;
}
Per the HTML5 spec (§13.3 Serialising HTML fragments), the only characters encoded inside the text content of an element are &, <, >, and U+00A0. " and ' are not encoded because in a text-content context they are not special. The helper is therefore safe in element-text contexts (where it is correctly used for name, version, description, etc.) but unsafe inside an attribute value, which is precisely where it is invoked for href on lines 432 and 426.
Impact
- Stored XSS on the official MCP Registry homepage. The malicious entry sits in the public catalogue alongside legitimate ones; any user expanding the entry triggers the payload.
- Because the page is served on the official
registry.modelcontextprotocol.ioorigin, the injected script can:- Read and overwrite
localStorage(baseUrl,customUrl), pinning the user's subsequent reads to an attacker-controlled "Custom" base URL. - Issue any same-origin or cross-origin XHR (
connect-src *is granted). - Phish for Registry JWTs by injecting fake auth flows on the trusted origin.
- Read and overwrite
- The CSP
script-src 'self' 'unsafe-inline' https://cdn.tailwindcss.comdoes not block this because'unsafe-inline'permits inline event-handler attributes.
Suggested remediation (any one suffices)
- Replace the homegrown
escapeHtmlwith an attribute-safe encoder that also escapes",', backtick, and=— the OWASP HTML attribute-encoding rule. - Avoid building the
hrefvia string templates. UsesetAttribute('href', value)instead —setAttributeis not subject to HTML tokenisation, so no breakout is possible. - Tighten
validateWebsiteURLto reject any URL whose raw bytes contain",',<,>,,\t, or\n, or — conservatively — store the canonical re-serialised form (parsedURL.String()percent-encodes such characters in the path). - Drop
'unsafe-inline'fromscript-srcafter auditing the inline scripts on the page.
Approach (3) is the smallest server-side change and immediately neutralises the exploit for any new publishes; approaches (1) or (2) close the class of bug at the sink so future fields with similar patterns are safe by default.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/modelcontextprotocol/registry | all versions | 1.7.7 |
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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/modelcontextprotocol/registry to 1.7.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rqv2-m695-f8j4 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 pinpoints whether GHSA-rqv2-m695-f8j4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-rqv2-m695-f8j4. 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-rqv2-m695-f8j4 in your dependencies?
O3 detects GHSA-rqv2-m695-f8j4 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.