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.
Summary
hono@4.12.14(published 2026-04-15) patches GHSA-458j-xx4x-4375 — an XSS via improper JSX attribute name handling inhono/jsxSSR (moderate, CVSS 4.3). The existing open Dependabot PR #1894 covers@hono/node-server1.19.11 → 1.19.13 but does not touchhonocore — likely becausehono@4.12.14post-dates the scan that opened that PR.Ask
Either include
hono@4.12.14in 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 permits4.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/sdkdo resolve to the latest patchedhonovia 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 CInpm auditflags the advisory. Every downstream has to independently notice and runnpm 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.14while this is getting sorted upstream.Reproduction
A fresh install resolves to
hono@4.12.14and audit is clean — this issue is specifically about the SDK's committed lockfile, not resolution behavior.