CVE-2025-53893: Filebrowser DoS Vulnerability

CVE-2025-53893 Overview

CVE-2025-53893 is a Denial of Service (DoS) vulnerability in File Browser version 2.38.0, an open-source web application that provides a file management interface within a specified directory. The flaw exists in the file read endpoint Filebrowser-Server-IP:PORT/files/{file-name}. The server loads the entire file content into memory during read operations without enforcing size checks or resource limits. An authenticated user can upload a large file and then trigger uncontrolled memory consumption by requesting it, causing the server process to exhaust available memory and become unresponsive. The issue is classified as [CWE-400] Uncontrolled Resource Consumption.

Critical Impact
An authenticated attacker can crash the File Browser service and render it unavailable to legitimate users by triggering memory exhaustion through a single large-file read request.

Affected Products

File Browser version 2.38.0
Deployments exposing the /files/{file-name} read endpoint
Any environment permitting authenticated user uploads to File Browser 2.38.0

Discovery Timeline

2025-07-15 - CVE-2025-53893 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-53893

Vulnerability Analysis

File Browser correctly handles and persists uploaded files to disk. The defect lies in the read path. When a client requests a file via the /files/{file-name} endpoint, the server buffers the full file content in memory before returning it. No streaming, chunking, or size ceiling is applied.

An authenticated user can upload an arbitrarily large file, then request that file to force the process to allocate memory proportional to the file size. Repeated or single sufficiently large reads exhaust the host's available memory, causing the File Browser process to crash or the underlying operating system to kill it. The application becomes unresponsive to legitimate clients until the process is restarted.

Root Cause

The root cause is missing resource governance in the file read handler. The implementation reads the file content in full rather than streaming bytes to the HTTP response. Because size validation and per-request memory limits are absent, attacker-controlled input directly drives server memory allocation, matching the pattern described by [CWE-400].

Attack Vector

The attack is network-based and requires authentication. An attacker with valid credentials, including any low-privilege account permitted to upload files, executes the following logical steps:

Authenticate to the File Browser instance.
Upload a large file to a writable directory.
Issue an HTTP GET to /files/{file-name} for the uploaded object.
The server attempts to load the entire file into memory, exhausting resources.

No verified public proof-of-concept code is published. See the GitHub Security Advisory GHSA-7xqm-7738-642x and the GitHub Issue Discussion for maintainer details.

Detection Methods for CVE-2025-53893

Indicators of Compromise

Sudden spikes in resident memory usage of the File Browser process correlated with GET requests to /files/{file-name}.
Out-of-memory (OOM) killer events targeting the File Browser process in system logs (dmesg, journalctl).
Unusually large files uploaded shortly before service degradation or crash.
Repeated HTTP GET requests from a single authenticated session against large stored objects.

Detection Strategies

Monitor File Browser access logs for GET requests to /files/ where response transfer sizes or response times are extreme outliers.
Alert on File Browser process restarts and OOM terminations reported by the host or container runtime.
Correlate upload events (POST /api/resources) that create large files with subsequent read requests from the same principal.

Monitoring Recommendations

Instrument the host with process-level memory and CPU telemetry and forward metrics to a centralized platform.
Track HTTP request duration, response bytes, and status per endpoint at the reverse proxy in front of File Browser.
Enable audit logging of authenticated uploads and downloads, retaining username, file path, and file size.

How to Mitigate CVE-2025-53893

Immediate Actions Required

Restrict network access to File Browser 2.38.0 to trusted users and networks until a fix is available.
Enforce upload size limits at the reverse proxy or ingress layer to cap the maximum file size that can be stored.
Review and reduce accounts with upload privileges to the minimum required set.
Place File Browser behind a proxy that enforces per-request response size and connection timeouts.

Patch Information

As of the CVE publication, the vendor advisory states that no known patches are available. Track the GitHub Security Advisory GHSA-7xqm-7738-642x and the related GitHub Issue Discussion for updates and apply fixes as soon as they are released by the File Browser maintainers.

Workarounds

Deploy File Browser inside a container with hard memory limits (for example, Docker --memory or Kubernetes resource limits) so a crash is contained and auto-restarted.
Configure the fronting reverse proxy (NGINX, Traefik, Caddy) to enforce client_max_body_size and response buffering limits that cap upload and download sizes.
Disable public exposure and require VPN or SSO gateway access to reduce the population of authenticated users.
Implement rate limiting on the /files/ path to slow repeated large-object reads from a single principal.

bash

# Example NGINX reverse proxy hardening in front of File Browser
server {
    listen 443 ssl;
    server_name files.example.com;

    # Cap upload size to blunt large-file abuse
    client_max_body_size 25m;

    # Limit request rate per client IP
    limit_req_zone $binary_remote_addr zone=fb_files:10m rate=10r/m;

    location /files/ {
        limit_req zone=fb_files burst=5 nodelay;
        proxy_read_timeout 30s;
        proxy_send_timeout 30s;
        proxy_pass http://127.0.0.1:8080;
    }

    location / {
        proxy_pass http://127.0.0.1:8080;
    }
}