File Browser TUS Negative Upload-Length Fires Post-Upload Hooks Prematurely
Date: 2026-03
Affected: go/github.com/filebrowser/filebrowser/v2
Attack vector: command-injection
Category: vulnerability-disclosure
Severity: Medium
CVE: CVE-2026-32759
CWE: CWE-190
CWE-20

> [!NOTE] > **This feature has been disabled by default for all installations from v2.33.8 onwards, including for existent installations**. To exploit this vulnerability, the instance administrator must turn on a feature and ignore all the warnings about known vulnerabilities. We're publishing this new advisory to make it clear that all vulnerabilities concerning this feature are disclosed. > > For more information about tracking vulnerability issues related to the Command Execution features, check https://github.com/filebrowser/filebrowser/issues/5199. ## Summary The TUS resumable upload handler parses the Upload-Length header as a signed 64-bit integer without validating that the value is non-negative. When a negative value is supplied (e.g. -1), the first PATCH request immediately satisfies the completion condition (newOffset >= uploadLength --> 0 >= -1), causing the server to fire after_upload exec hooks with a partial or empty file. An authenticated user with upload permission can trigger any configured after_upload hook an unlimited number of times for any filename they choose, regardless of whether the file was actually uploaded - with zero bytes written. ## Details **Affected file:** http/tus_handlers.go **Vulnerable code - POST (register upload):** ```go func getUploadLength(r *http.Request) (int64, error) { uploadOffset, err := strconv.ParseInt(r.Header.Get("Upload-Length"), 10, 64) if err != nil { return 0, fmt.Errorf("invalid upload length: %w"


Mitigations:

Architectural layers (MAESTRO):