filebrowser CVE-2026-82238

Exploitation requires a valid authenticated session with at least low-privileged upload access to a filebrowser instance running version 2.24.0 or later. The TUS resumable upload feature must be active and reachable. The attacker must be able to issue multiple concurrent PATCH requests to the same upload endpoint - this requires the ability to open parallel HTTP connections, which is standard but introduces timing sensitivity (AC:H). Non-default configuration or special roles are not required beyond having upload permission. Exploitation is limited by: (1) requirement for a valid authenticated account, (2) race-condition timing that may not succeed on every attempt, and (3) the impact being confined to file-size limit bypass and hook triggering rather than arbitrary code execution or data exfiltration.

The CVSS 4.0 score of 2.3 (Low) reflects a realistic but constrained threat: attack complexity is High (AC:H) due to race condition timing requirements, AT:P indicates a prerequisite attack condition, and PR:L confirms that a valid authenticated session is mandatory. The vulnerability has no confidentiality or integrity impact on the vulnerable system per the supplied vector (VC:N/VI:N), only low availability impact (VA:L) - though the description implies some integrity effect from oversized file writes, suggesting a possible discrepancy worth verifying with the vendor. EPSS data was not provided, but given AC:H, PR:L, and no KEV listing, real-world mass exploitation is unlikely; the attack requires precise concurrency timing and an authenticated account. A mid-sized self-hosted deployment presents meaningful exposure only if untrusted authenticated users have upload access. The 'Authentication Bypass' tag in the input appears to refer to bypassing upload-length enforcement, not authentication itself - this label should not be interpreted as unauthenticated exploitability.

An authenticated user with upload privileges sends a large number of simultaneous PATCH requests to the TUS endpoint targeting the same Upload-Offset value on an in-progress upload. Because the length check and the write are not atomic, multiple requests pass validation concurrently, each appending data independently and collectively exceeding the Upload-Length declared at session creation. The resulting oversized file may then trigger any configured upload-completion webhooks or processing hooks, potentially abusing downstream file handling logic.