[BitL8-ByteShort]

Outcome

Dependabot alerts #5 and #6 flag GHSA-46jr-4wx8-v453: one HTTP request within the default body-size limit could exhaust server memory while the MCP SDK validated unbounded arrays and object keys. This moves the affected runtime package to a patched release and turns on the new argument cap, which the patched SDK leaves off.

The required Verify job also runs npm audit --audit-level=high. That step was failing on two high findings that were already in the tree: Vite 8.3.1 and transitive source-map-js 1.2.1. Both are updated to patched versions so the gate is clear.

Advisory and version bump

The MCP advisory covers two packages:

Package	Affected	Patched
@modelcontextprotocol/sdk	>= 1.3.0, < 1.32.0	1.32.0
@modelcontextprotocol/server	>= 2.0.0, < 2.3.0	2.3.0

This repo does not depend on @modelcontextprotocol/sdk. The direct dependency is @modelcontextprotocol/server 2.2.0, which is inside the affected range. The latest published release is 2.3.1 (2026-10-05). Its own note is a @modelcontextprotocol/core bump; the validation limit landed in 2.3.0. Both @modelcontextprotocol/server and the devDependency @modelcontextprotocol/client are now pinned to 2.3.1, and the lockfile resolves a single @modelcontextprotocol/core@2.3.1.

The client package is not named by this advisory. It moves with the server because the v2 SDK packages share one core and are released together. Leaving the client on 2.2.0 would install a second core beside the server.

2.3.0 also refuses to share one McpServer across connections. This process already passes serveStdio a factory that builds a new server per connection, which is the pattern that release keeps working. There is no MCP HTTP transport here, so maxRequestBodySize does not apply. The advisory states that stdio-only servers are not on the HTTP request path that triggers the exhaustion.

Upgrading alone does not enable the new limit. get_model_status takes no arguments and route_task takes at most task and modality, so the server now sets maxToolInputElements: 32. A call over that cap is answered with isError: true before schema validation. A normal two-field route call is unchanged.

Audit gate

Verify / verify (24.x) failed only on npm audit --audit-level=high. Tests had already passed. The report was:

• source-map-js 1.0.0–1.2.1 (GHSA-68fv-2mgg-jv7q), pulled in by PostCSS.
• vite 8.3.0–8.3.2 (launch-editor and dev-server advisories). npm's fix is 8.3.5.

Vite is now pinned to 8.3.5. That release depends on postcss ^8.5.30, and the lockfile resolves PostCSS 8.5.31 with source-map-js 1.2.2. Rolldown moves from 1.2.11 to 1.2.15 with it, which is the range Vite 8.3.5 requires. These are patch updates inside the existing major versions.

Verification

• npm ci installed from the updated lockfile.
• npm audit --audit-level=high reports 0 vulnerabilities.
• npm run verify (tsc --noEmit, node --test, vite build with Vite 8.3.5): 352 passed, 0 failed, 3 skipped. The skips are the existing OpenCode host checks (OpenCode is not installed in this environment).
• The element-cap test fails if maxToolInputElements is removed and passes with the cap set.
• npm run test:browser: 14 passed.

Safety and compatibility

• Free and legacy verified-price Paid still reject unknown pricing; configured Paid still checks connection identity, availability, and capabilities.
• Paid routing remains an explicit user choice and cannot bypass capability gates.
• No credentials, private prompts, customer data, absolute user paths, or generated local settings are included.
• OpenCode config writes are explicit, receipt-owned, recoverable, and preserve unrelated settings.
• New behavior includes failure-path coverage where relevant.
• I signed off my commits according to the DCO in CONTRIBUTING.md.