Fix vulnerable MCP SDK dependency

[zw5]

Summary

• update @modelcontextprotocol/sdk to the patched 1.29.x line
• refresh package-lock.json so the production dependency graph resolves to patched SDK transitives
• adjust HTTP transport setup for the current SDK types under exactOptionalPropertyTypes

Verification

• npm audit --omit=dev --json reports 0 production vulnerabilities
• npm ci --ignore-scripts
• npm run build
• npm test (52 passed, 6 skipped)

This addresses the public MCP TypeScript SDK advisories reported by npm audit, including the URI template ReDoS and cross-client data leak findings.

[domdomegg]

Removing this will turn this into a stateful server, which I don't think we want to do

[zw5]

Thanks for catching this.
I amended the branch to restore the explicit stateless setting with sessionIdGenerator: undefined. The remaining cast is limited to the options object because SDK 1.29 rejects that explicit undefined under exactOptionalPropertyTypes.

[domdomegg]

FYI: https://overreacted.io/npm-audit-broken-by-design/

I'm unsure if we're actually vulnerable here, and I've been burned many times updating the SDK so am kinda spooked by this

[zw5]

Fair point. npm audit alone would be a bad reason to take this.

In this case the package is the direct runtime MCP SDK this server imports for stdio/HTTP, not a random nested dependency. The diff only bumps @modelcontextprotocol/sdk, refreshes the lockfile, and makes the small HTTP transport type fix needed after the SDK bump.

I reran GitHub CI (current and lts both pass), plus local npm ci --ignore-scripts, npm run build, npm test (52 passed, 6 skipped), and npm audit --omit=dev --json (0 prod findings).

If you would rather do the SDK bump yourself, no problem. Close this and treat the diff/test list as a reference.

[zw5]

This PR keeps the server on @modelcontextprotocol/sdk 1.29 while preserving both stdio and HTTP startup paths. The only source change is the SDK 1.29 transport typing adjustment in src/main.ts; the rest is the lockfile refresh. CI passes on current and LTS Node, and my local build/test/prod-audit checks passed. If you take the SDK bump later in another branch, src/main.ts is the compatibility change to carry over.

[domdomegg]

tldr: I'm going to close this for now: it introduces a failure mode that breaks the HTTP server, and doesn't actually fix any security issues.

---

I took a deeper look at what was being changed by this PR.

The two SDK advisories don't actually apply to this server:

• GHSA-8r9q-7v3j-jr4g (URI template ReDoS): only reachable via ResourceTemplates with exploded array patterns. We only register tools, not resources, so the code path isn't reachable.
• GHSA-345p-7cg4-v4c7 (cross-client leak): structurally applied to HTTP mode (single shared transport + server reused across /mcp requests). The advisory's prescribed fix is per-request construction of both, which I've landed in Fix HTTP transport cross-client response misrouting #104.

Additionally, this PR as written would have broken the server in HTTP mode. SDK 1.26+ adds a runtime guard that throws unconditionally on the second handleRequest call to a stateless transport — and src/main.ts here still has the shared-transport pattern (this PR only adjusts the type imports). Verified in 1.29.0's source: if (!this.sessionIdGenerator && this._hasHandledRequest) throw new Error('Stateless transport cannot be reused across requests'). So after this merged, the HTTP server would have served exactly one request and thrown on every one after that — sequential or concurrent. Tests didn't catch it because at the time this PR was opened the suite had no HTTP transport coverage.

The ajv and path-to-regexp findings also don't apply here — no $data option in schemas, and /mcp is a static route.

Also because 1.29.0 has an upstream typing bug it needs as unknown as Transport casts, which makes the dep bump also kinda ugly and these kinds of type casts make errors and security bugs more likely in future - so I'm hesitant to introduce them.

[zw5]

Well, thank you anyways for reviewing this PR, I see now why it doesn’t really fit the project, sorry if I wasted your time.