An HTTP client sends a very large POST body or an extreme JSON-RPC batch. Without SDK-level bounds, the server parses and processes work under its own tool-serving event loop; a batch can monopolize time even when total bytes are limited. The advisory states affected Streamable HTTP MCP servers did not bound POST size or batch message count, allowing…
Inspect the ClaimsCase · DiggingBeagle record
MCP TypeScript HTTP services could exhaust resources on oversized bodies or batches
The SDK allowed an untrusted HTTP client to force excessive parsing work even when conventional proxy body limits were considered.
Scope
Unauthenticated reachability depends on whether application-layer authorization runs before the SDK. Stdio-only deployments are unaffected.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
The reviewed SDK advisory identifies an HTTP transport admission flaw and enumerates patched npm versions, 4 MiB body limits and 100-operation batch caps. stdio-only configurations and upstream app authentication change reachability; no real service outage is documented. Impact is left ungraded because a calibrated 0-to-4 impact basis for actual affected targets is unavailable from these Claims.
Assessed Oct 28, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-CP22-029-A · CLM-CP22-029-B · CLM-ENRICH-20261028-008 · MCP TypeScript SDK unbounded HTTP body and JSON-RPC batch advisory
At a glance
The advisory does not establish widespread service outages, and separate identity/routing issues must not be merged with this resource-exhaustion mechanism.
Limits and uncertaintyFull account
An HTTP client sends a very large POST body or an extreme JSON-RPC batch. Without SDK-level bounds, the server parses and processes work under its own tool-serving event loop; a batch can monopolize time even when total bytes are limited.
The advisory states affected Streamable HTTP MCP servers did not bound POST size or batch message count, allowing memory exhaustion or denial of service depending on deployment exposure. The listed patched releases introduce a default 4 MiB body limit and 100-message batch cap with 413 and 400 responses, respectively. Primary evidence.
Unauthenticated reachability depends on whether application-layer authorization runs before the SDK. Stdio-only deployments are unaffected.
Apply the patched SDK and enforce limits across body bytes, batch count, concurrent operations and per-user resource budgets.
Claims & evidence
CLM-CP22-029-AThe advisory states affected Streamable HTTP MCP servers did not bound POST size or batch message count, allowing memory exhaustion or denial of service depending on deployment exposure.supported
Basis: reported finding
- supportsMCP TypeScript SDK unbounded HTTP body and JSON-RPC batch advisoryprimary disclosure
Advisory summary; transport and handler limits
CLM-CP22-029-BThe listed patched releases introduce a default 4 MiB body limit and 100-message batch cap with 413 and 400 responses, respectively.supported
Basis: reported finding
- supportsMCP TypeScript SDK unbounded HTTP body and JSON-RPC batch advisoryprimary disclosure
Advisory fix; patched versions and enforced limits
CLM-ENRICH-20261028-008The advisory limits the exposure to affected HTTP server transports; it says stdio-only servers are not affected and an HTTP body parser alone does not cap JSON-RPC batch length.supported
Basis: reported finding
- supportsMCP TypeScript SDK unbounded HTTP body and JSON-RPC batch advisoryprimary disclosure
Am I affected? and Fix, GHSA-f897-62hf-6gxq
Controls and mitigations
- Apply the patched SDK and enforce limits across body bytes, batch count, concurrent operations and per-user resource budgets.
Unknowns and contradictions
- The advisory does not establish widespread service outages, and separate identity/routing issues must not be merged with this resource-exhaustion mechanism.
Sources and citation
Material revision history
- Oct 28, 2026 · Canonical change recorded · new in release · revision 199