CVE-2026-88045

## Summary In streamed multipart mode, `serve s3` passes the request's declared part length to `multipart.NewRW().Reserve(contentLength)` before reading any part data. `Reserve` immediately obtains enough 1 MiB pool pages for the entire declared length. The request handler therefore allocates attacker-selected memory based only on `Content-Length` or `X-Amz-Decoded-Content-Length`; the client does not need to transmit the corresponding body. `--multipart-streaming-buffer-limit` does not stop the allocation for the current expected part or for one oversized part when the buffer is empty. That exception is intentional to guarantee upload progress, and the flag's short help is scoped to out-of-order parts; this report therefore does not treat the option as a total memory cap. The security issue is the absence of a separate safe maximum or incremental allocation: a small request header can cause an arbitrarily large reservation and exhaust the process or host. The default S3 configuration allows anonymous access when no `auth_key` is set, so an unauthenticated network client can reach the path in such deployments. Authenticated deployments require a valid S3 credential. Confirmed affected targets are `v1.75.0` and development commit `5629f2668c69149bf3d9d8e2a25bb32a2648606e`, both of which include streamed multipart support. ## Affected Assets & Attack Surface - `cmd/serve/s3/s3.go:40-46` defines the streaming buffer limit and describes it as a limit for out-of-order parts. - `cmd/serve/s3/server.go:67-101` permits anonymous requests when `AuthKey` is empty and configures S3 authentication otherwise. - `cmd/serve/s3/multipart.go:183-209` admits the declared part size and calls `Reserve(contentLength)` before `io.Copy` reads the body. - `cmd/serve/s3/multipart.go:220-238` always admits the current expected part and one oversized part when the buffer is empty, even when `size > bufferLimit`. - `lib/multipart/multipart.go:23-24` creates an RW backed by the global memo