Bump hono and fast-uri to versions covering published GHSA advisories

Summary

@modelcontextprotocol/sdk@1.29.0 declares dependencies on hono ^4.11.4 and (transitively, via ajv ^8.17.1) fast-uri. Both have published GitHub Security Advisories that are visible to every SDK consumer's Dependabot dashboard. This issue requests a coordinated bump to versions that cover them.

Affected advisories

fast-uri (HIGH × 2 — runtime)

• GHSA-v39h-62p7-jpjc — host confusion via percent-encoded authority delimiters. Vulnerable: ≤ 3.1.1, first patched: 3.1.2.
• GHSA-q3j6-qgpj-74h6 — path traversal via percent-encoded dot segments. Vulnerable: ≤ 3.1.0, first patched: 3.1.1.

Path: fast-uri ← ajv@8.18.0 ← @modelcontextprotocol/sdk.

hono (5 advisories spanning low → moderate)

• GHSA-9vqf-7f2p-gf9v — bodyLimit() bypass for chunked / unknown-length requests
• GHSA-69xw-7hcm-h432 — hono/jsx unvalidated tag names allow HTML injection
• GHSA-p77w-8qqv-26rm — Cache Middleware ignores Vary: Authorization / Vary: Cookie
• GHSA-qp7p-654g-cw7p — CSS Declaration Injection in JSX SSR
• GHSA-hm8q-7f3q-5f36 — JWT NumericDate (exp / nbf / iat) validation

Reachability for our consumer (FYI, may help triage)

We're an SDK consumer (@iris-eval/mcp-server). The reachability picture from our side:

• hono is loaded by exactly one file in the SDK — dist/esm/examples/server/honoWebStandardStreamableHttp.js. That file is in the examples/ tree and isn't transitively imported from @modelcontextprotocol/sdk/server/mcp.js or .../server/streamableHttp.js. So although hono is in our node_modules/, no hono module loads into our process — we run StreamableHTTPServerTransport from inside an Express app.
• fast-uri is reachable through ajv's URI format validation, but URI format checks aren't a security boundary in well-written consumers (we do our own scheme allowlist + private-IP block + DNS pre-resolve before fetching).

So most consumers are probably not exploitable on these. But the advisories are still surfaced to every consumer's Security tab, and downstream-of-downstream visibility is real friction — we just spent a session triaging them, documenting the reachability analysis in our repo, and dismissing where appropriate.

Ask

• Bump hono to a version covering those five advisories (current upstream releases address them).
• Bump ajv (or pin fast-uri directly) so that fast-uri ≥ 3.1.2 resolves transitively.
• If examples/server/honoWebStandardStreamableHttp.js is intentionally a server framework demo and not a runtime path the SDK uses, consider whether hono could be a peerDependency / optionalDependency rather than a direct dependency — that's the cleanest way to take it out of every consumer's dep tree by default.

What we did on our side (in case it's useful)

• Added package.json overrides.fast-uri = "^3.1.2" to force the patched fast-uri across our tree (cheap defense in depth even where reachability says safe).
• Documented every advisory's per-surface threat-model in SECURITY-EXPOSURE.md — load-graph reachability, code-path reachability, untrusted-input reachability, downstream guards, decision.
• Added a CI gate (scripts/security/check-exposure-coverage.mjs) that fails any PR which surfaces a new ≥medium advisory without a documented row.

Happy to PR the bump if it would help.

Start by inspecting the SDK package manifests and the entry point dist/esm/examples/server/honoWebStandardStreamableHttp.js to confirm how hono is declared and used. Check the resolved ajv and fast-uri versions, then run the repository's dependency checks and tests. Done means the advisories are covered and the dependency choice for the example is intentional.