Cloudreve is a self-hosted file management and sharing system. Prior to 4.17.0, the built-in thumbnail and avatar image decoders limit compressed file size but do not limit decoded pixel dimensions, allowing an authenticated user to submit a small PNG, JPEG, or GIF that triggers an unbounded allocation and terminates the Cloudreve process through fatal out-of-memory behavior. This issue is fixed in version 4.17.0.

Affected: Go: github.com/cloudreve/Cloudreve/v4, Go: github.com/cloudreve/Cloudreve/v3

## Summary

Cloudreve's built-in image processor decodes user-supplied images with Go's standard-library decoders (`image/png`, `image/jpeg`, `image/gif`) and guards **only the compressed file size** — never the *decoded* pixel dimensions. Go's decoders allocate a pixel buffer sized `bytesPerPixel × width × height` taken straight from the image header (e.g. a PNG's IHDR), with no upper bound on `width`/`height`. A tiny (tens-of-bytes) image that *declares* enormous dimensions therefore forces a multi-gigabyte-to-terabyte allocation (`make([]uint8, …)`), exhausting memory. The resulting out-of-memory condition is a **fatal Go runtime error / kernel OOM-kill that `recover()` cannot catch**, terminating the whole Cloudreve process for all users.

Two reachable sinks share the same root cause:

1. **Avatar upload** (`PUT /api/v4/user/setting/avatar`) — decodes synchronously in the request handler. Any authenticated user. **Cleanest single-request PoC.** 2. **Thumbnail generation** (built-in generator, **enabled by default**) — decodes in the thumbnail queue worker. Reachable for the user's own files *and* for files inside a share, so a planted bomb can be (re)triggered through a public share link.

Post-auth, low privilege. A single 65-byte upload deterministically takes the instance offline.

### Details ### Root cause — decode guarded by file size, not pixel count

The built-in generator is the **default** image thumbnailer:

```go // inventory/setting.go @ 26b6b10 "thumb_bui…