security(mcp): enforce request-body limits on actual streamed bytes #371

Summary

createAskableMcpWebHandler() documents/enforces a request-body limit, but the current implementation only trusts the client-supplied Content-Length header. A chunked/serverless Fetch request without that header—or a request declaring a falsely small value—bypasses the default 1 MiB protection and is fully handed to the MCP transport.

Evidence

• packages/mcp/src/index.ts:532 calls isRequestBodyTooLarge().
• isRequestBodyTooLarge() at roughly lines 923–930 returns false when Content-Length is absent and only compares the declared number.
• Existing tests use truthful Content-Length values, so they do not exercise actual streamed byte count.

Risk

A remote client can force excessive body parsing, memory allocation, and CPU use. This is particularly relevant in Fetch/serverless deployments where chunked requests commonly omit Content-Length.

Proposed fix

• Keep the header comparison as an early rejection.
• For body-bearing requests, consume through a bounded reader and stop once the actual byte count exceeds the limit.
• Reconstruct a Request for accepted bodies before passing it to the MCP transport.
• Preserve maxRequestBodyBytes: false behavior.

Acceptance criteria

• Oversized body without Content-Length returns 413
• Oversized body with a falsely small header returns 413
• Exact-boundary body succeeds
• Truthfully oversized header is rejected before reading the body
• Disabled limit preserves current behavior
• MCP web-handler tests cover streamed/chunked bodies