Published consumers still resolve a vulnerable @hono/node-server (overrides are root-only)

[lazyants]

Split out of #80 at review request.

What

npm honours overrides only from the install root, never from an installed dependency's manifest. #80 refreshed this repo's override pins and cleared its CI audit gate, but that does not propagate to npx/npm install consumers of @lazyants/lexware-mcp-server.

Measured

npm pack from #80's head, installed into an empty project (2026-07-27):

Package	Consumer resolves	Patched?
hono	4.12.32	✅ SDK's ^4.11.4 already permits the fix
fast-uri	3.1.4	✅ ajv's ^3.0.1 permits it
body-parser	2.3.0	✅ express's range permits it
@hono/node-server	1.19.15	❌ 3 moderate findings

So three of four resolve safely for consumers anyway — npm picks the newest version satisfying the declared ranges, and those ranges already allow the patched releases.

Why the last one cannot be fixed from here

GHSA-frvp-7c67-39w9 has range < 2.0.5, i.e. every 1.x is affected and there is no 1.x patch. @modelcontextprotocol/sdk@1.29.0 declares @hono/node-server: ^1.19.9. No resolution npm can perform crosses that major boundary without an override at the consumer's own install root.

Adding @hono/node-server to our dependencies does not help: ^2.0.10 conflicts with the SDK's ^1.19.9, so npm installs ours at the root and the SDK still gets a nested 1.x.

Runtime impact: none

This server only uses StdioServerTransport. Walking the ESM import graph from src/server.ts reaches no hono code — only sdk/server/streamableHttp.js imports it, and nothing we load imports that. Since ESM imports are static, the code is never loaded into the process. The impact is that a consumer's own npm audit goes red, not that they are exploitable through us.

Options

1. Upstream (preferred): ask @modelcontextprotocol/sdk to widen/bump its @hono/node-server range to ^2. Blocks on their release cadence.
2. Wait for an SDK release that does so, then drop our override.
3. Document the expected npm audit output for consumers in SECURITY.md.

Fleet-wide: hetzner-mcp-server and transkribus-mcp-server depend on the same SDK and are equally affected.

Found by the lazy-ants-reviewer bot on #80, which reproduced it independently.