deps: include hono@4.12.14 in the next dependabot bump (GHSA-458j-xx4x-4375)

Summary

hono@4.12.14 (published 2026-04-15) patches GHSA-458j-xx4x-4375 — an XSS via improper JSX attribute name handling in hono/jsx SSR (moderate, CVSS 4.3). The existing open Dependabot PR #1894 covers @hono/node-server 1.19.11 → 1.19.13 but does not touch hono core — likely because hono@4.12.14 post-dates the scan that opened that PR.

Ask

Either include hono@4.12.14 in the next refresh of #1894, or let Dependabot re-scan so it picks up the new version. The SDK's current caret range (hono: ^4.11.4) already permits 4.12.14, so this is a lockfile-only change within the SDK.

Why this is worth a nudge even though caret ranges permit the patched version

Agreed upfront with the reasoning from #1810: fresh installs of @modelcontextprotocol/sdk do resolve to the latest patched hono via the existing caret range, so new consumers are safe automatically. This isn't a request to raise the declared floor.

The practical reason to still refresh the SDK's own committed lockfile: downstream server repos that commit their own package-lock.json (which is common for reproducible CI) inherit a stale hono pin through a fresh install only if they re-resolve. Until they do, their CI npm audit flags the advisory. Every downstream has to independently notice and run npm update hono. An SDK-side lockfile refresh isn't load-bearing for consumer safety, but it keeps the advisory out of the ecosystem's CI dashboards one step earlier.

Happy to close if this is already tracked or queued behind #1894.

Context

One downstream patch in progress: Grey-Iris/easy-notion-mcp#30 refreshes our own lockfile to hono@4.12.14 while this is getting sorted upstream.

Reproduction

mkdir /tmp/hono-cve && cd /tmp/hono-cve
npm init -y
npm install @modelcontextprotocol/sdk@1.29.0
npm audit --json | jq '.vulnerabilities.hono.via[0].url'
# "https://github.com/advisories/GHSA-458j-xx4x-4375"

A fresh install resolves to hono@4.12.14 and audit is clean — this issue is specifically about the SDK's committed lockfile, not resolution behavior.

Inspect the SDK's committed lockfile and the existing Dependabot PR #1894 first; the issue says the declared hono range already permits 4.12.14. Reproduce with the provided npm install and npm audit commands, then confirm the lockfile refresh resolves the advisory without changing the dependency floor.