CVE-2026-32759: 
NixOS vulnerability analysis and mitigation

CVE-2026-32759 is a TUS resumable upload handler vulnerability in File Browser (filebrowser) that allows authenticated users to prematurely fire post-upload exec hooks by supplying a negative Upload-Length header value. Affecting all 2.x branch versions prior to 2.33.8 (the GitHub Advisory Database lists affected versions as < 2.33.8 for the Go module github.com/filebrowser/filebrowser/v2), the flaw was published on March 14, 2026, and added to the NVD on March 20, 2026. It carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 5.3 (Medium) (GitHub Advisory, Filebrowser Advisory).

The root cause is improper input validation (CWE-20) combined with an integer sign handling flaw (CWE-190) in http/tus_handlers.go. The getUploadLength() function parses the Upload-Length HTTP header using strconv.ParseInt as a signed 64-bit integer without checking that the result is non-negative. When a value such as -1 is supplied, the PATCH handler's completion check (newOffset >= uploadLength, i.e., 0 >= -1) evaluates to true immediately, causing the server to invoke after_upload exec hooks with an empty or partial file on the very first PATCH request. An attacker with upload permissions can repeat this POST+PATCH cycle indefinitely, triggering hooks with arbitrary attacker-controlled filenames and zero bytes written. A public PoC bash script demonstrating the full exploit flow is included in the GitHub security advisory (GitHub Advisory, Filebrowser Advisory).

When enableExec is enabled, an authenticated attacker can repeatedly trigger after_upload exec hooks with attacker-controlled filenames, enabling denial of service through expensive processing hooks (e.g., virus scanning, transcoding, ML inference), command injection amplification when combined with malicious filenames in shell-wrapped hooks (effectively achieving remote code execution), and abuse of upload-driven business logic workflows such as S3 ingestion, database inserts, or notifications with empty payloads. Even without exec hooks, the vulnerability creates inconsistent upload cache entries where files are marked complete but contain zero bytes, causing subsequent reads to return empty files. All deployments using the /api/tus endpoint are affected, with the enableExec flag escalating impact from cache inconsistency to full remote command execution (GitHub Advisory, Filebrowser Issue #5199).

A complete proof-of-concept bash script is publicly available in the GitHub security advisory, demonstrating login, crafted TUS requests with Upload-Length: -1, and repeated hook triggering. As of the time of reporting, there is no evidence of active in-the-wild exploitation, and no threat actor attribution has been made. The EPSS score is approximately 0.184% (35th percentile), indicating a currently low but non-negligible probability of exploitation. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires authenticated access (low privileges) but no user interaction, and the attack complexity is low (GitHub Advisory, Feedly).

1. Authenticate: Obtain a valid session token by sending a POST request to /api/login with valid credentials (e.g., curl -s -X POST "$TARGET/api/login" -H 'Content-Type: application/json' -d '{"username":"attacker","password":"Attack3r!pass"}').
2. Initiate TUS upload with negative length: Send a POST request to /api/tus/<filename> with the header Upload-Length: -1 and Content-Length: 0. This registers the upload in the server cache with a negative length value.
3. Send empty PATCH request: Send a PATCH request to /api/tus/<filename> with headers Upload-Offset: 0, Content-Type: application/offset+octet-stream, and Content-Length: 0. Because 0 >= -1 evaluates to true, the server immediately marks the upload complete and fires the after_upload exec hook.
4. Repeat to amplify impact: Loop the POST+PATCH cycle with different filenames (e.g., /spam_hook_1.txt, /spam_hook_2.txt) to trigger the hook an unlimited number of times, causing DoS through resource exhaustion or, if exec hooks use filenames in shell commands, achieving remote code execution via command injection.
5. Achieve objective: If enableExec is true and hooks pass the filename to a shell command, craft a malicious filename containing shell metacharacters to inject arbitrary commands executed by the server process (GitHub Advisory, Filebrowser Advisory).

• Network: Repeated HTTP POST requests to /api/tus/<filename> followed immediately by PATCH requests with Content-Length: 0 and Upload-Length: -1 headers; high-frequency TUS upload initiation from a single authenticated user.
• Logs: File Browser access logs showing rapid sequences of POST /api/tus/ and PATCH /api/tus/ requests with zero-byte bodies; hook execution log entries (e.g., /tmp/hook_log.txt) showing HOOK_FIRED entries for files that do not exist or are empty on disk.
• File System: Presence of zero-byte files in the File Browser serve directory corresponding to attacker-supplied filenames; unexpected output files from exec hooks (e.g., log files written by hook scripts) with entries for non-existent uploads.
• Process: Unusual child processes spawned by the File Browser process (e.g., bash, sh) with attacker-controlled arguments or filenames; repeated execution of hook scripts in rapid succession without corresponding legitimate file uploads (GitHub Advisory).

Starting from version 2.33.8, the command execution (enableExec) feature is disabled by default for all installations, including existing ones, which eliminates the highest-severity impact of this vulnerability. Administrators should upgrade to File Browser v2.33.8 or later; if upgrading is not immediately possible, ensure the enableExec flag is explicitly disabled (do not use --disable-exec=false or FB_DISABLE_EXEC=false). Additional mitigations include implementing rate limiting on the /api/tus endpoint, validating and sanitizing filenames before passing them to hook scripts, and monitoring file contents before processing hooks. The maintainers have noted that the command execution feature should not be used in untrusted environments and recommend against re-enabling it (GitHub Advisory, Filebrowser Issue #5199).

The File Browser maintainer (hacdias) published the advisory on March 14, 2026, explicitly noting that the command execution feature has been disabled by default from v2.33.8 onwards and that the feature should not be used in untrusted environments. The maintainers also opened a tracking issue (#5199) acknowledging a pattern of security vulnerabilities in the command execution feature and announcing a decision to disable it by default pending a full rewrite. The vulnerability was detected by Qualys (detection ID 761875) and picked up by SUSE/openSUSE security announcements. No significant independent researcher commentary or major media coverage has been identified beyond standard vulnerability database aggregation (Filebrowser Advisory, Filebrowser Issue #5199).