Unbounded gzip decompression in MultipartFormWithLimit(0) streaming path

[
  {
    "finding_title": "Unbounded gzip decompression in MultipartFormWithLimit(0) streaming path",
    "verdict": "INVALID",
    "reasoning": "The report claims that `MultipartFormWithLimit(0)` allows unbounded memory allocation when processing a gzip-compressed multipart body stream. I examined the `MultipartFormWithLimit` function in `http.go`. In the streaming path (`req.bodyStream != nil`), if `Content-Encoding` is `gzip`, the code wraps the body stream in a `gzip.NewReader`. If `maxBodySize > 0`, it wraps this in an `io.LimitedReader`. However, if `maxBodySize` is 0 (the default), no `LimitedReader` is applied. The decompressed stream is then passed to `multipart.NewReader(...).ReadForm(8 * 1024)`. The `ReadForm` method of `multipart.Reader` will read file parts into memory up to the specified size (8KB) but will write larger parts to temporary files. Crucially, the memory allocated for the decompression buffer and the multipart parsing logic (headers, small parts) is bounded by the structure of the multipart data and the temporary file threshold. A gzip bomb typically involves a small compressed size decompressing to a huge size. However, `multipart/form-data` requires specific boundaries. An attacker cannot create a valid multipart stream where the entire decompressed payload is a single huge binary blob without headers, because `ReadForm` parses the structure. More importantly, even if a huge file part is created, it is written to a temp file, not memory. The memory consumption is bounded by the multipart headers and the 8KB in-memory limit for parts. The `gzip.NewReader` itself does not allocate unbounded memory for the decompressed output; it streams it. The `multipart.Reader` streams it to disk or memory (bounded). Therefore, there is no unbounded *memory* allocation that leads to OOM. The threat model concerns memory safety and integrity. While disk usage could be a concern, the specific claim is about memory allocation (OOM). Since the decompressed data is streamed to the multipart parser which offloads large parts to disk, the memory footprint remains bounded. Thus, the claim of unbounded memory allocation leading to OOM is false. The bug pattern (missing limit check) exists, but the consequence (unbounded memory) does not hold because the underlying `multipart.Reader` handles large parts via temp files.\n\nCRUX: Does multipart.Reader.ReadForm allocate unbounded memory for large file parts when the input stream is unlimited?\nGREP: ReadForm",
    "elapsed": 59.7,
    "tokens": 25114,
    "tokens_in": 24593,
    "tokens_out": 521,
    "cost_usd": 0.01189206,
    "file": "http.go",
    "round": 1,
    "grep_used": true,
    "grep_results": "GREP `ReadForm`:\n```\nserver_test.go:342:\tf, err := mr.ReadForm(64)\nhttp_test.go:2862:\tform, err := mr.ReadForm(1024)\nhttp.go:1145:\t\treq.multipartForm, err = mr.ReadForm(8 * 1024)\nhttp.go:1247:\tf, err := mr.ReadForm(int64(maxInMemoryFileSize))\n```"
  },
  {
    "finding_title": "Unbounded gzip decompression in MultipartFormWithLimit(0) streaming path",
    "verdict": "VALID",
    "reasoning": "The report claims that `MultipartFormWithLimit(0)` (the default) leads to unbounded memory allocation when processing a gzip-compressed multipart body stream, causing OOM/DoS. The vulnerability lies in the `bodyStream != nil` path of `MultipartFormWithLimit`. In this path, if `Content-Encoding: gzip` is present, the body stream is wrapped in `gzip.NewReader`. A `LimitedReader` is only applied if `maxBodySize > 0`. With the default `maxBodySize` of 0, no limit is applied to the decompressed stream. This unlimited decompressed stream is then passed to `multipart.NewReader(...).ReadForm(8 * 1024)`. \n\nAlthough `multipart.Reader.ReadForm` streams parts larger than the in-memory limit (8KB) to disk, it still parses the stream in chunks and accumulates the `multipart.FileHeader` and `Value` data in memory. More critically, a 'gzip bomb' can be crafted to decompress into a stream of valid multipart headers or small parts that are all under the 8KB threshold, or simply a stream of data that forces the multipart parser to allocate memory for parsing logic or if the attacker crafts a malformed stream that causes the parser to buffer large amounts of data before failing. Even if the main body is streamed to disk, the lack of a hard stop on the decompression process means an attacker can force the server to decompress and process an arbitrarily large amount of data. While the primary storage for large files is disk, the absence of a limit on the total processed bytes means that the CPU and disk I/O resources are consumed unboundedly. Furthermore, if the attacker crafts a payload where the multipart boundaries are spaced such that parts remain small in memory but the total volume is huge, or if they exploit a parser quirk where it buffers significantly, memory usage can still spike. However, the most definitive issue is that the `gzip.NewReader` decompression itself is not bounded. `gzip.NewReader` allocates buffers as it reads. If the input is a valid gzip stream that decompresses to gigabytes, the `gzip` reader will continue to read and decompress. While `multipart.Reader` handles the output, the `gzip` decompression logic still requires processing. \n\nActually, let's look closer at `multipart.Reader.ReadForm`. It iterates through parts. For each part, if it's a file and larger than the limit, it streams to a temp file. If it's a value, it reads it into memory (capped by the limit? No, `ReadForm`'s limit applies to the file part memory threshold, but values are usually small). \n\nThe key is that `MultipartFormWithLimit(0)` is a public API. An attacker can send a request with `Content-Encoding: gzip` and a `Content-Type: multipart/form-data`. The body is streamed. The library decompresses it. If the decompressed data is huge, the `multipart` parser must process it. Even if it streams to disk, the *resource consumption* (disk space, CPU time, network I/O for reading the decompressed data) is unbounded because there is no `maxBodySize` check on the decompressed stream. The threat model includes \"resource bounds (unbounded allocation, algorithmic complexity, infinite loops on crafted input)\". An unbounded disk write or CPU usage is a valid DoS vector. \n\nFurthermore, `multipart.Reader.ReadForm` returns an error if the multipart stream is malformed. But a valid gzip bomb that decompresses to a valid, extremely large multipart form (e.g., many small fields or one huge file) will be processed. If it's one huge file, it goes to disk. But the server is now writing an arbitrary amount of data to disk, controlled by the attacker (via the decompression ratio). This is a Disk Exhaustion DoS. The threat model explicitly lists \"resource bounds... unbounded allocation\". Writing unbounded data to disk is a resource bound issue. \n\nAdditionally, if the attacker sends a stream that causes the `multipart` parser to accumulate data in memory (e.g. if the boundaries are missing or malformed in a way that causes it to buffer until error), memory could also be exhausted. But the disk exhaustion is sufficient for a DoS. \n\nThe specific claim is \"unbounded memory allocation... leading to OOM\". While `ReadForm` mitigates *memory* exhaustion for large file parts by using temp files, it does not mitigate *disk* exhaustion or *CPU* exhaustion. The report focuses on memory, but the underlying issue (missing limit on decompressed stream) leads to resource exhaustion (disk/CPU) which is a valid security vulnerability under the threat model. However, the report specifically says \"leading to OOM\". Is the OOM claim false? Yes, for the main file content, it goes to disk. But `multipart.Form` holds `Value` fields in memory. An attacker could send a gzip bomb that decompresses to many small multipart fields (values). `ReadForm` stores these in `form.Value`. If there are millions of small fields, `form.Value` will grow unboundedly in memory. This leads to OOM. \n\nExample: A gzip stream that decompresses to: \n`boundary=xyz\r\nContent-Disposition: form-data; name=\"a\"\r\n\r\nA\r\n--xyz\r\n...` repeated millions of times. \nEach field is small, so it stays in memory. The total memory usage grows linearly with the number of fields, which is unbounded. \n\nTherefore, the bug is real. An attacker can trigger it by sending a gzipped multipart body with many small fields (or a large file causing disk exhaustion, but the small fields cause memory exhaustion). The `maxBodySize=0` allows this. \n\nThe prior reviewer dismissed the memory concern because they assumed the main payload is a large file streamed to disk. They missed the vector of many small fields (values) which are kept in memory, or the disk exhaustion vector. \n\nVerdict: VALID. The missing limit allows an attacker to cause unbounded resource consumption (Memory via many small fields, or Disk via large files), leading to DoS.\n\nCRUX: Does an attacker-controlled gzip stream passed to MultipartFormWithLimit(0) allow unbounded accumulation of multipart form values in memory or unbounded disk writes?\nGREP: ReadForm",
    "elapsed": 177.2,
    "tokens": 26729,
    "tokens_in": 25354,
    "tokens_out": 1375,
    "cost_usd": 0.01477368,
    "file": "http.go",
    "round": 2,
    "grep_used": true,
    "grep_results": "GREP `ReadForm`:\n```\nhttp_test.go:2862:\tform, err := mr.ReadForm(1024)\nserver_test.go:342:\tf, err := mr.ReadForm(64)\nhttp.go:1145:\t\treq.multipartForm, err = mr.ReadForm(8 * 1024)\nhttp.go:1247:\tf, err := mr.ReadForm(int64(maxInMemoryFileSize))\n```"
  },
  {
    "finding_title": "Unbounded gzip decompression in MultipartFormWithLimit(0) streaming path",
    "verdict": "VALID",
    "reasoning": "The report identifies a missing size limit in the streaming path of `MultipartFormWithLimit(0)`. When `Content-Encoding: gzip` is present, the body is decompressed via `gzip.NewReader`. If `maxBodySize` is 0, no `io.LimitedReader` is applied to the decompressed stream before passing it to `multipart.NewReader().ReadForm(8 * 1024)`. While `ReadForm` streams large file parts to disk, it stores form *values* (fields) in memory within the `multipart.Form` struct. An attacker can craft a gzip bomb that decompresses to a massive number of small form fields (values), causing unbounded memory allocation and OOM. Additionally, even if parts are streamed to disk, the lack of a limit on total decompressed bytes allows for unbounded disk consumption and CPU exhaustion. Since `MultipartForm()` (the default) calls `MultipartFormWithLimit(0)`, this is reachable by default when handling multipart requests with gzip encoding. The threat model explicitly includes \"unbounded allocation\" and \"resource bounds\" as valid DoS vectors. The absence of a limit here allows an external attacker to exhaust host resources.\n\nCRUX: MultipartFormWithLimit(0) applies no limit to the decompressed gzip stream, allowing unbounded memory/disk usage via crafted input.\nGREP: MultipartFormWithLimit",
    "elapsed": 101.9,
    "tokens": 27083,
    "tokens_in": 26778,
    "tokens_out": 305,
    "cost_usd": 0.01216176,
    "file": "http.go",
    "round": 3,
    "grep_used": true,
    "grep_results": "GREP `MultipartFormWithLimit`:\n```\nREADME.md:382:    For untrusted multipart input, use [ctx.MultipartFormWithLimit()](https://pkg.go.dev/github.com/valyala/fasthttp#RequestCtx.MultipartFormWithLimit) (or a custom [Server.FormValueFunc](https://pkg.go.dev/github.com/valyala/fasthttp#Server)) to enforce a parsing size limit.\nserver.go:237:\t// provide a custom FormValueFunc and call MultipartFormWithLimit() there.\nserver.go:1104:// This method is equivalent to MultipartFormWithLimit(0), i.e. no body size\nserver.go:1120:// MultipartFormWithLimit returns request's multipart form and limits the read\nserver.go:1127:func (ctx *RequestCtx) MultipartFormWithLimit(maxBodySize int) (*multipart.Form, error) {\nserver.go:1128:\treturn ctx.Request.MultipartFormWithLimit(maxBodySize)\nserver.go:1140:// For multipart requests with untrusted input, call MultipartFormWithLimit()\nserver.go:1232:// MultipartFormWithLimit() before FormValue or provide a custom\nserver.go:1233:// Server.FormValueFunc that uses MultipartFormWithLimit().\nhttp_test.go:526:func TestRequestMultipartFormWithLimitGzip(t *testing.T) {\nhttp_test.go:547:\t\t_, err := req.MultipartFormWithLimit(len(formBody) - 1)\nhttp_test.go:559:\t\t_, err := req.MultipartFormWithLimit(len(formBody) - 1)\nhttp_test.go:571:\t\tf, err := req.MultipartFormWithLimit(len(formBody))\nhttp.go:1094:// This method is equivalent to MultipartFormWithLimit(0), i.e. no body size\nhttp.go:1100:\treturn req.MultipartFormWithLimit(0)\nhttp.go:1103:// MultipartFormWithLimit returns request's multipart form and limits the\nhttp.go:1113:func (req *Request) MultipartFormWithLimit(maxBodySize int) (*multipart.Form, error) {\n```"
  },
  {
    "finding_title": "Unbounded gzip decompression in MultipartFormWithLimit(0) streaming path",
    "verdict": "VALID",
    "reasoning": "The report claims that `MultipartFormWithLimit(0)` allows unbounded memory allocation via a gzip bomb in the streaming path. I examined the code flow in `http.go`. When `req.bodyStream != nil` and `Content-Encoding: gzip` is present, the body stream is wrapped in `gzip.NewReader`. If `maxBodySize <= 0`, no `io.LimitedReader` is applied to the decompressed stream. This unlimited decompressed stream is then passed to `multipart.NewReader(...).ReadForm(8 * 1024)`. \n\nThe key vulnerability is that `multipart.Reader.ReadForm` stores form **values** (fields that are not files, i.e., `form-data; name=\"key\"`) directly into memory within the `multipart.Form` struct (`f.Value` map). It only streams **file** parts (parts with a `filename` header) to temporary files if they exceed the `maxInMemory` limit (8KB). An attacker can craft a valid gzip stream that decompresses into a multipart body containing millions of small form fields (values). Since these values are not streamed to disk but are instead read into memory and accumulated in the `Form` struct, an attacker can cause unbounded memory consumption (OOM) by sending a small gzipped payload that expands to a huge number of small fields. Additionally, even for large files, the lack of a limit allows unbounded disk usage (Disk Exhaustion DoS). The threat model explicitly includes \"unbounded allocation\" and \"resource bounds\" as valid DoS vectors. The default call `MultipartForm()` uses `maxBodySize=0`, making this reachable by default. The absence of a limit on the decompressed stream is a real security flaw allowing resource exhaustion.\n\nCRUX: Does MultipartFormWithLimit(0) apply a size limit to the decompressed gzip stream before parsing, and does ReadForm store all form data in memory or stream it to disk?\nGREP: ReadForm",
    "elapsed": 230.2,
    "tokens": 27984,
    "tokens_in": 27557,
    "tokens_out": 427,
    "cost_usd": 0.012854939999999999,
    "file": "http.go",
    "round": 4,
    "grep_used": true,
    "grep_results": "GREP `ReadForm`:\n```\nserver_test.go:342:\tf, err := mr.ReadForm(64)\nhttp_test.go:2862:\tform, err := mr.ReadForm(1024)\nhttp.go:1145:\t\treq.multipartForm, err = mr.ReadForm(8 * 1024)\nhttp.go:1247:\tf, err := mr.ReadForm(int64(maxInMemoryFileSize))\n```"
  },
  {
    "finding_title": "Unbounded gzip decompression in MultipartFormWithLimit(0) streaming path",
    "verdict": "INVALID",
    "reasoning": "The report claims that `MultipartFormWithLimit(0)` (the default) allows unbounded memory allocation (OOM) when processing a gzip-compressed multipart body stream because no `io.LimitedReader` is applied to the decompressed stream. I examined the code in `http.go`. Specifically, in the `bodyStream != nil` path, if `Content-Encoding: gzip` is present, the stream is wrapped in `gzip.NewReader`. If `maxBodySize > 0`, an `io.LimitedReader` is applied; otherwise, it is not. The resulting stream is passed to `multipart.NewReader(...).ReadForm(8 * 1024)`. The key question is whether `ReadForm` allocates unbounded memory for a huge decompressed stream. `multipart.Reader.ReadForm` parses the multipart stream. For file parts larger than the `maxInMemory` threshold (8KB in this case), it creates a temporary file and streams the data to it. It does *not* load the entire file content into memory. For value fields (non-file parts), it stores them in the `Form.Value` map. An attacker could theoretically craft a gzip bomb that decompresses to a multipart body with millions of small value fields to cause memory exhaustion, but the primary vector of a 'gzip bomb' (high compression ratio of a single large payload) would typically be a file upload or a large continuous blob. If it's a file, it goes to disk (bounded memory, unbounded disk). If it's a single large value, `ReadForm` would read it into memory until EOF, which could cause OOM. However, the standard threat model for HTTP servers usually relies on `maxMemory` and `maxBodySize` to prevent resource exhaustion. The library provides `MultipartFormWithLimit` specifically to allow setting these bounds. The default behavior of using limit 0 is a convenience feature that places the burden on the application to set limits if they are processing untrusted input with high compression ratios. More importantly, the 'unbounded memory allocation' claim for the *standard* gzip bomb case (large file) is incorrect because it streams to disk. The 'unbounded memory' via millions of small fields is a valid DoS vector but is a secondary interpretation. However, looking at the threat model rules: 'The public API must validate all inputs.' But the API explicitly states `MultipartFormWithLimit(0)` means 'no limit is applied'. It is the user's choice to call the default method. If the user calls `MultipartForm()` (default), they are opting for no limit. Is the library failing to validate? The library *does* allow the user to validate via the `WithLimit` variant. The 'bug' is that the *default* is unsafe for untrusted input with high compression. In security triage, if a library function has an unsafe default that can be easily configured to be safe, and the documentation warns to use the safe variant for untrusted input (as seen in grep results: 'For untrusted multipart input, use ctx.MultipartFormWithLimit()'), this is often considered a 'secure by default' issue or a misconfiguration rather than a flaw in the library's logic itself, unless the 'unsafe' default is unavoidable. Here, it is avoidable. However, the prompt asks if the bug is real and attacker-reachable. The attacker sends a request. The server app (using the library) calls `MultipartForm()`. The library processes it. If the app didn't set a limit, the app is responsible for that choice. The library itself isn't 'buggy' in the sense of ignoring a constraint; it is operating as documented. The 'vulnerability' is in the *application's* decision to use the default limit for untrusted gzip-compressed input. Therefore, marking this as a library vulnerability is invalid; it is a code quality/secure-by-default concern or an application configuration issue. Since the library provides the means to prevent it (the `WithLimit` function) and documents it, the library is not inherently vulnerable in a way that the developer cannot mitigate. The 'unbounded memory' claim for the main body of the request is false due to disk streaming. The 'unbounded memory' via small fields is a valid DoS but depends on the app not setting a limit. Given the library's explicit provision of the limit and documentation, this is not a VALID security vulnerability in the library itself.\n\nCRUX: Does the library force unbounded memory allocation in a way that cannot be mitigated by the application, or does it provide a documented mechanism (MultipartFormWithLimit) to prevent it, making the default unsafe behavior an application configuration issue?\nGREP: MultipartFormWithLimit",
    "elapsed": 98.6,
    "tokens": 28735,
    "tokens_in": 27736,
    "tokens_out": 999,
    "cost_usd": 0.014646119999999999,
    "file": "http.go",
    "round": 5,
    "grep_used": true,
    "grep_results": "GREP `MultipartFormWithLimit`:\n```\nREADME.md:382:    For untrusted multipart input, use [ctx.MultipartFormWithLimit()](https://pkg.go.dev/github.com/valyala/fasthttp#RequestCtx.MultipartFormWithLimit) (or a custom [Server.FormValueFunc](https://pkg.go.dev/github.com/valyala/fasthttp#Server)) to enforce a parsing size limit.\nserver.go:237:\t// provide a custom FormValueFunc and call MultipartFormWithLimit() there.\nserver.go:1104:// This method is equivalent to MultipartFormWithLimit(0), i.e. no body size\nserver.go:1120:// MultipartFormWithLimit returns request's multipart form and limits the read\nserver.go:1127:func (ctx *RequestCtx) MultipartFormWithLimit(maxBodySize int) (*multipart.Form, error) {\nserver.go:1128:\treturn ctx.Request.MultipartFormWithLimit(maxBodySize)\nserver.go:1140:// For multipart requests with untrusted input, call MultipartFormWithLimit()\nserver.go:1232:// MultipartFormWithLimit() before FormValue or provide a custom\nserver.go:1233:// Server.FormValueFunc that uses MultipartFormWithLimit().\nhttp_test.go:526:func TestRequestMultipartFormWithLimitGzip(t *testing.T) {\nhttp_test.go:547:\t\t_, err := req.MultipartFormWithLimit(len(formBody) - 1)\nhttp_test.go:559:\t\t_, err := req.MultipartFormWithLimit(len(formBody) - 1)\nhttp_test.go:571:\t\tf, err := req.MultipartFormWithLimit(len(formBody))\nhttp.go:1094:// This method is equivalent to MultipartFormWithLimit(0), i.e. no body size\nhttp.go:1100:\treturn req.MultipartFormWithLimit(0)\nhttp.go:1103:// MultipartFormWithLimit returns request's multipart form and limits the\nhttp.go:1113:func (req *Request) MultipartFormWithLimit(maxBodySize int) (*multipart.Form, error) {\n```\n\nGREP `results:`:\n```\n(no matches in repo)\n```"
  },
  {
    "verdict": "VALID",
    "reasoning": "[ARBITER] The vulnerability exists in the `MultipartFormWithLimit` function within `http.go`. When processing a request with a `bodyStream` (common for large uploads or when using `ReadLimitBody` with streaming) and `Content-Encoding: gzip`, the code wraps the stream in `gzip.NewReader`. If `maxBodySize` is 0 (which is the default when calling `MultipartForm()`, which delegates to `MultipartFormWithLimit(0)`), no `io.LimitedReader` is applied to the decompressed stream. This results in `multipart.NewReader` receiving an unbounded reader. An attacker can send a small gzip-compressed body with a high compression ratio (gzip bomb) that decompresses to a massive size. The `ReadForm` method will then allocate unbounded memory to store the form fields or files, leading to an Out-Of-Memory (OOM) condition and Denial of Service. The library does not enforce a default limit on the decompressed size when the limit is explicitly set to 0 or not provided via the default `MultipartForm()` call.",
    "round": 6,
    "file": "http.go",
    "finding_title": "Unbounded gzip decompression in MultipartFormWithLimit(0) streaming path",
    "elapsed": 140.6,
    "tokens_in": 25387,
    "tokens_out": 243,
    "cost_usd": 0.01139154
  }
]