CVE-2026-32759: Filebrowser Filebrowser RCE Vulnerability

CVE-2026-32759 Overview

File Browser is a popular file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. A vulnerability has been identified in versions 2.61.2 and below where the TUS resumable upload handler improperly parses the Upload-Length header as a signed 64-bit integer without validating that the value is non-negative. This integer overflow vulnerability (CWE-190) allows an authenticated user to supply a negative value that instantly satisfies the upload completion condition upon the first PATCH request.

Critical Impact

This vulnerability enables attackers to trigger exec hooks with empty or partial files, leading to denial of service, command injection amplification with malicious filenames, or abuse of upload-driven workflows. When enableExec is enabled, impact escalates from cache inconsistency to potential remote command execution.

Affected Products

• File Browser versions 2.61.2 and below
• All deployments using the TUS upload endpoint (/api/tus)
• Configurations with enableExec flag enabled (elevated risk)

Discovery Timeline

• 2026-03-20 - CVE-2026-32759 published to NVD
• 2026-03-23 - Last updated in NVD database

Technical Details for CVE-2026-32759

Vulnerability Analysis

The vulnerability resides in the TUS (resumable upload) handler implementation within File Browser. The TUS protocol is designed to allow resumable file uploads, where the client specifies the total file size via the Upload-Length header. The application parses this header value as a signed 64-bit integer but fails to validate that the provided value is non-negative.

When an authenticated attacker supplies a negative value in the Upload-Length header, the server's internal upload completion logic is immediately satisfied upon the first PATCH request. This occurs because the comparison check that determines whether an upload is complete (bytes received >= expected length) evaluates to true when the expected length is negative, as any non-negative number of received bytes will be greater than a negative expected length.

The impact manifests in multiple ways depending on deployment configuration. At a baseline, all affected deployments experience cache inconsistency where files are marked as complete but contain no actual data. When exec hooks are configured via the enableExec flag, the server fires after_upload hooks with empty or partial files, enabling attackers to repeatedly trigger configured hooks with arbitrary filenames and zero bytes written.

Root Cause

The root cause is improper input validation of the Upload-Length HTTP header in the TUS upload handler. The application accepts signed integer values without boundary checking, failing to reject negative values that violate the TUS protocol specification. This represents a classic integer overflow vulnerability (CWE-190) where the absence of non-negative validation allows exploitation of signed/unsigned integer comparison semantics.

Attack Vector

The attack is network-based and requires authentication to the File Browser application. An attacker with valid credentials can exploit this vulnerability by:

1. Initiating a TUS upload session to the /api/tus endpoint
2. Setting the Upload-Length header to a negative value (e.g., -1)
3. Sending a PATCH request with minimal or no file content
4. The server interprets the upload as complete due to the negative length comparison

This causes immediate triggering of any configured after_upload exec hooks. The attacker can repeat this process to create a denial of service through expensive processing hooks, amplify command injection attacks when combined with malicious filenames, or abuse upload-driven workflows such as S3 ingestion or database inserts.

The vulnerability is described in the GitHub Security Advisory GHSA-ffx7-75gc-jg7c and tracked in GitHub Issue #5199.

Detection Methods for CVE-2026-32759

Indicators of Compromise

• Unusual TUS upload requests to /api/tus with negative Upload-Length header values
• Exec hook executions triggered for files with zero or unexpectedly small file sizes
• Presence of empty or corrupted files in the upload directory marked as complete
• Repeated rapid upload completion events from the same authenticated user

Detection Strategies

• Monitor HTTP request logs for Upload-Length headers containing negative integer values
• Implement web application firewall (WAF) rules to block requests with negative Upload-Length values
• Audit exec hook execution logs for patterns indicating trigger abuse (high frequency, zero-byte files)
• Review file system integrity for zero-byte files that were processed as complete uploads

Monitoring Recommendations

• Enable verbose logging on the File Browser application to capture header values
• Set up alerting for anomalous upload patterns, particularly rapid completion of uploads
• Monitor system resource utilization for signs of DoS via hook exhaustion
• Track file creation events in upload directories for zero-byte file anomalies

How to Mitigate CVE-2026-32759

Immediate Actions Required

• Disable the enableExec flag if not strictly required to reduce impact from cache inconsistency to preventing remote command execution
• Implement reverse proxy rules to validate and reject negative Upload-Length header values
• Restrict access to the /api/tus endpoint to trusted users only
• Review and audit all configured exec hooks for potential abuse vectors

Patch Information

At the time of publication, no official patch or mitigation was available from the vendor to address this issue. Monitor the GitHub Security Advisory for updates on patch availability.

Workarounds

• Disable the TUS upload endpoint (/api/tus) if resumable uploads are not required for your deployment
• Implement input validation at the reverse proxy level using nginx or similar to reject requests with negative Upload-Length values
• Remove or disable all exec hooks until a patch is available
• Consider implementing rate limiting on the TUS endpoint to reduce DoS impact

# Example nginx configuration to block negative Upload-Length values
# Add to your server block handling File Browser
location /api/tus {
    # Block requests with negative Upload-Length header
    if ($http_upload_length ~* "^-") {
        return 400;
    }
    proxy_pass http://filebrowser_backend;
}