stacklok / toolhive / 34207786236

71%

Build Type

push

github

Committed by web-flow

Commit Message

Merge commit from fork

ToolHive's tool allowlist (--tools CLI flag, or spec.toolsFilter under the
Kubernetes operator's MCPToolConfig CRD) could be bypassed in both
directions by prefixing an MCP JSON-RPC message with a three-byte UTF-8
BOM. Go's encoding/json treats a leading BOM as a syntax error rather than
whitespace, while WHATWG-decoding consumers (the MCP TypeScript SDK,
browsers, Node) strip it silently before parsing, so the filter failed to
parse the message and forwarded it unfiltered.

In the response direction, only one of the three tools/list response
handling branches stripped the BOM; the other two did not, and a
terminal parse failure wrote the buffered body through unfiltered rather
than blocking it. In the request direction, an unmarshal failure on a
BOM-prefixed tools/call left the middleware unable to make a filtering
decision at all, forwarding the request verbatim to the backend.

Strip the BOM once, before dispatch, on both paths: in drainBuffer before
the response media-type switch, and in the tool-call middleware before
parsing, rewriting the forwarded request body (not just a parse-time
copy) so the filter and the backend can never disagree about what bytes
are being acted on. The same normalization is applied in the shared MCP
request parser, so authorization, audit, telemetry, and rate limiting all
decide on the same bytes the backend will execute.

Fixes GHSA-9v4w-3mqh-6vmm.

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

Coverage Stats

6 of 6 new or added lines in 2 files covered. (100.0%)

17 existing lines in 6 files now uncovered.

79070 of 112668 relevant lines covered (70.18%)

91.73 hits per line