The TUS upload handler in File Browser parses the Upload-Length header as a signed 64‑bit integer without verifying that the value is non‑negative. An authenticated user can send a negative value in the first PATCH request, which causes the server to believe the upload is complete immediately. This triggers any configured post‑upload execution hooks with empty or partial files, allowing the attacker to repeatedly fire hooks with arbitrary filenames and zero bytes.“ The lack of validation also creates cache inconsistencies where files appear complete but contain no data, potentially disrupting workflows that rely on the upload status. Once execution hooks are enabled, the vulnerability can be leveraged for higher‑level attacks, such as command injection when malicious filenames are supplied, or to inject data into downstream systems like S3 or databases.

All deployments of File Browser that expose the TUS upload endpoint (/api/tus) are affected. The vulnerability applies to the filebrowser:filebrowser product in any version 2.61.2 or older. All instances that use the enableExec flag to run custom hooks are at greater risk, while those that do not may still suffer from cache corruption and denial of service conditions.

The CVSS score is 5.3, indicating a moderate severity potential, while the EPSS score is below 1%, suggesting low current exploit probability. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires authenticated access; an attacker who can authenticate to the File Browser API can craft the negative Upload-Length header to trigger hooks or corrupt the file cache. If the enableExec flag is used, the risk escalates from a service disruption to remote command execution or even broader data tampering, depending on what the hooks are configured to perform.