CVE-2026-72838: 
Wolfi vulnerability analysis and mitigation

CVE-2026-72838 is a Denial of Service vulnerability in FileBrowser caused by the TUS resumable-upload PATCH endpoint failing to enforce the declared Upload-Length, allowing authenticated users to exhaust disk space. It affects all FileBrowser versions before 2.63.19 (confirmed through v2.63.18). The vulnerability was reported against FileBrowser v2.63.14 and disclosed on August 14, 2026, with a patch released the same day. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, Github Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling). In http/tus_handlers.go, the tusPatchHandler function used io.Copy to write the full request body to disk without bounding the write to the declared Upload-Length - Upload-Offset. The declared upload length was only consulted after writing to determine upload completion, meaning a client could declare a small Upload-Length (e.g., 1 KB) at upload creation and then send an arbitrarily large body (e.g., 50 MB) in a single PATCH request, which the server would write entirely to disk and return HTTP 204. The fix in commit 4daddec6 wraps the body reader with io.LimitReader(r.Body, remaining+1), rejects PATCH requests where the offset already exceeds the declared length with HTTP 400, and rolls back and rejects oversized bodies with HTTP 413 (GitHub Advisory, Fix Commit).

Successful exploitation allows any authenticated user with ordinary file create/write permissions to exhaust the filesystem used by FileBrowser by repeatedly sending oversized PATCH requests to the TUS upload endpoint. Once disk space is exhausted, FileBrowser and any other services sharing the same storage volume may become unavailable or fail unpredictably. There is no confidentiality or integrity impact; the vulnerability is purely an availability (Denial of Service) issue with no lateral movement potential beyond shared storage disruption (GitHub Advisory, Feedly).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation as of the disclosure date. CISA's SSVC assessment (added August 17, 2026) classifies exploitation as "none" and the vulnerability as not automatable with partial technical impact. The EPSS score is approximately 0.295% (22nd percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory, NVD).

1. Authenticate: Obtain valid credentials for a FileBrowser account with at least file create/write permissions on any accessible directory.
2. Initiate a TUS upload: Send a TUS POST request to /api/tus/ with a small Upload-Length header (e.g., Upload-Length: 1024) to create a new resumable upload session and receive an upload URL.
3. Send an oversized PATCH request: Send a PATCH request to the returned upload URL with Upload-Offset: 0 and a request body significantly larger than the declared Upload-Length (e.g., 50 MB of arbitrary data).
4. Observe server acceptance: On vulnerable versions (before 2.63.19), the server writes the full oversized body to disk and returns HTTP 204, despite the declared 1 KB limit.
5. Repeat to exhaust disk: Automate or repeat the oversized PATCH requests in a loop to rapidly fill the available disk space, causing FileBrowser and co-located services to become unavailable (GitHub Advisory).

• Network: Repeated PATCH requests to /api/tus/ endpoints with large Content-Length values significantly exceeding the Upload-Length declared in the corresponding upload creation request; high-volume sustained upload traffic from a single authenticated user.
• Logs: FileBrowser access logs showing multiple PATCH requests to TUS upload paths returning HTTP 204 with response bodies indicating large byte counts written; discrepancy between declared Upload-Length and actual bytes transferred.
• File System: Rapid, unexpected growth in the FileBrowser data directory; presence of large files (tens or hundreds of MB) in upload staging areas inconsistent with normal user activity; filesystem approaching or at capacity.
• Process/System: Disk usage alerts or filesystem-full errors on the host or container running FileBrowser; other services on the same storage volume failing due to insufficient disk space (GitHub Advisory).

Upgrade FileBrowser to version 2.63.19 or later, which enforces the declared Upload-Length on TUS PATCH requests, rejects offsets exceeding the declared length with HTTP 400, and rolls back and rejects oversized bodies with HTTP 413. No official workaround exists for unpatched versions; the advisory explicitly states "None. Upgrade to v2.63.19." As interim mitigations, operators can implement reverse-proxy request body size limits (e.g., client_max_body_size in Nginx), apply filesystem or container-level disk quotas to the FileBrowser data directory, and monitor for rapid disk consumption (GitHub Advisory, Fix Commit).