Open
Conversation
3 tasks
The validating and mutating webhook middlewares both called io.ReadAll on the inbound HTTP request body with no size cap before forwarding to the configured webhook server. The client side correctly limited the response body via io.LimitReader to MaxResponseSize, but the server side missed the symmetric limit on inbound requests, so the webhook package would buffer arbitrarily large bodies into memory. Wrap r.Body with http.MaxBytesReader at MaxRequestSize (1 MB, symmetric to MaxResponseSize) and return HTTP 413 with a JSON-RPC error envelope when the limit is exceeded. Reject the read before any forwarding. Note: this is the webhook-layer cap. mcp.ParsingMiddleware sits earlier in the proxy chain and currently reads the body unbounded; capping inbound bodies at the MCP parsing layer is tracked separately and is the load-bearing fix against upstream DoS. This change still bounds the webhook package's own re-read buffer and lays the symmetry groundwork. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
JAORMX
force-pushed
the
pr/webhook-request-size-limit
branch
from
5ddece0 to
db55923
Compare
github-actions
Bot
added
size/S
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5192 +/- ##
==========================================
+ Coverage 67.64% 67.69% +0.05%
==========================================
Files 606 606
Lines 61797 61807 +10
==========================================
+ Hits 41801 41843 +42
+ Misses 16839 16805 -34
- Partials 3157 3159 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to the round-2 review of #4564 (item #9).
pkg/webhook/validating/middleware.goandpkg/webhook/mutating/middleware.goboth calledio.ReadAllon the inbound HTTP request body with no size cap before forwarding to the configured webhook server. The client side correctly limited response bodies viaio.LimitReadertoMaxResponseSize; the server side missed the symmetric limit on inbound requests, so the webhook package would buffer arbitrarily large bodies into memory.This PR wraps
r.Bodywithhttp.MaxBytesReaderatMaxRequestSize(1 MB, symmetric toMaxResponseSize) and returns HTTP 413 with a JSON-RPC error envelope when the limit is exceeded. The read is rejected before any forwarding.Type of change
Test plan
task test—pkg/webhook/...passes with-race)golangci-lintreports 0 issues)TestValidatingMiddleware_RequestBodySizeLimitandTestMutatingMiddleware_RequestBodySizeLimitcover the over-limit (413 + JSON-RPC envelope) and exact-boundary (accepted) cases.Special notes for reviewers
mcp.ParsingMiddleware(pkg/mcp/parser.go:85) sits earlier in the proxy middleware chain and currently reads the body unbounded itself, so the structural fix against upstream DoS is to also cap at the MCP parsing layer. That's a separate concern and a separate change set; the cap here still bounds the webhook package's own re-read buffer and lays the symmetry groundwork. I will open a tracking issue for the MCP-layer cap.MaxResponseSizeand is comfortable for typical MCPtools/callpayloads. If a real workload needs larger bodies we can lift the cap with a config knob; today there's no such use case in tree.🤖 Generated with Claude Code