Unbounded memory allocation in http_listener_v2 collectBody() - snappy and default encoding paths

[calvinmachado20]

Relevant code

The collectBody() method correctly wraps the gzip path with http.MaxBytesReader to enforce max_body_size, but the Snappy and default (uncompressed) encoding paths call io.ReadAll(req.Body) directly without any size constraints.

This allows an attacker to send an arbitrarily large HTTP request body that will be fully read into memory, potentially causing OOM conditions and crashing the process.

Affected paths include:

1. Snappy path (~line 301)
2. Default path (~line 327)

While the method does check req.ContentLength > int64(h.MaxBodySize) at the top of serveWrite(), the Content-Length header is optional and can be omitted or spoofed by the client. The actual request body must be bound independently.

Logs

None

System info

Latest version

Docker

No response

Steps to reproduce

1. Send an HTTP request to the affected endpoint without a Content-Length header.
2. Provide a request body larger than the configured max_body_size.
3. Observe that the request body is fully read into memory by the Snappy or default encoding path.

Expected behavior

The request body should be independently bounded by max_body_size regardless of whether the client provides a Content-Length header.

Actual behavior

The Snappy and default (uncompressed) encoding paths call io.ReadAll(req.Body) without applying a size limit. An attacker can therefore cause arbitrarily large request bodies to be loaded into memory, potentially resulting in OOM conditions and process crashes.

Additional info

The gzip path already uses http.MaxBytesReader to enforce the configured body-size limit. The same protection should be applied to the Snappy and default encoding paths.