stacklok / toolhive / 27423098940

push

github

Enforce request body size limits on proxies and vMCP (#5492)

* Extract request body size limit into pkg/bodylimit

The 1MB request-body cap and 413 handling lived only in the management
API server, leaving the MCP proxies and vMCP exposed to memory
exhaustion from large/unbounded request bodies (GHSA-grwg-v9p7-76m2).

Move the middleware and its helpers into a reusable pkg/bodylimit
package exposing both a net/http middleware and a runner middleware
factory, so every inbound listener can share one trusted implementation.
A non-positive limit falls back to the default (zero never means
unlimited). The API server now consumes the package with no behavior
change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Enforce request body size limit on proxies and vMCP

Wire the body-limit middleware into the proxy middleware chain and the
vMCP server so oversized request bodies are rejected with 413 before any
handler buffers them via io.ReadAll, closing the DoS exposure in
GHSA-grwg-v9p7-76m2 for default deployments.

Register bodylimit in the middleware factory and prepend it as the
outermost entry in PopulateMiddlewareConfigs so it runs before auth and
the MCP parser. Apply the same middleware in the vMCP handler, inside
recovery, preserving SSE streams via the response-writer Unwrap/Flush
forwarding. Tests cover 413 rejection, the bounded downstream read that
guards chain ordering, and SSE survival.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Return 413 on oversized chunked proxy bodies; add transport tests

When an oversized body arrives without a Content-Length (chunked), the
early Content-Length check is bypassed and the cap is enforced by
http.MaxBytesReader inside the handler's io.ReadAll. The streamable and
httpsse handlers reported that as 500; map the MaxBytesError to 413 so
the documented contract holds on the chunked path too.

Add body-limit smoke tests for all three proxy transports (streama... (continued)

155 of 170 new or added lines in 11 files covered. (91.18%)

68069 of 102247 relevant lines covered (66.57%)

62.98 hits per line