CVE-2026-90927 in Filebrowser
Summary
by MITRE • 09/14/2026
filebrowser through 2.63.23 fails to limit WebSocket message size in the /api/command handler before checking permissions, allowing authenticated users to buffer arbitrarily large messages. Attackers can send oversized WebSocket messages to exhaust server heap memory and cause denial of service regardless of EnableExec setting or Execute permission.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in FileBrowser versions up to 2.63.23 represents a critical resource exhaustion flaw within the application's WebSocket handling mechanism, specifically targeting the /api/command endpoint. This issue stems from an architectural oversight where the system processes incoming WebSocket messages for size validation prior to performing authentication and authorization checks. In standard secure design patterns, access control decisions should precede any significant processing of user-supplied data to prevent unauthenticated or unauthorized actors from consuming server resources during the evaluation phase. By reversing this order, FileBrowser inadvertently allows authenticated users to trigger memory allocation operations without first verifying if they possess the necessary permissions to execute commands via WebSocket.
From a technical perspective, the flaw lies in the sequence of operations within the command handler logic. When a client establishes a WebSocket connection and sends a message intended for command execution, the server immediately attempts to parse and buffer this data into memory based on its size before consulting the user's permission set or checking if the EnableExec feature is active. This pre-authentication resource allocation means that even users with minimal privileges, such as those restricted from executing commands via other interfaces like the web UI, can exploit this path. The attacker simply needs to be a valid authenticated user and then transmit WebSocket frames containing arbitrarily large payloads. Because there is no upper limit enforced on the message size prior to memory reservation, the server allocates heap space proportional to the incoming data volume.
The operational impact of this vulnerability is severe, primarily manifesting as a Denial of Service (DoS) condition against the FileBrowser instance and potentially the underlying host system. As an attacker sends oversized messages repeatedly or in rapid succession, the server's memory consumption increases linearly with each request until it exhausts available heap space. This leads to application instability, potential crashes due to OutOfMemory errors, or significant performance degradation that affects legitimate users attempting to access file services. Notably, this exploit bypasses security controls such as the EnableExec flag and Execute permission settings because the resource exhaustion occurs before these checks are evaluated. Consequently, even if command execution is strictly disabled for a user account via standard configuration methods, they can still leverage their authenticated WebSocket session to destabilize the service.
This vulnerability aligns with CWE-787: Out-of-bounds Write in terms of memory management principles and more accurately maps to CWE-400: Uncontrolled Resource Consumption, as it involves the allocation of excessive server resources leading to denial of service. In the context of the MITRE ATT&CK framework, this behavior is consistent with T1498: Network Denial of Service, specifically under techniques that involve flooding or resource exhaustion through application-layer protocols like WebSocket. The attack vector leverages authenticated access, which classifies it as an insider threat scenario or a compromised credential exploitation rather than an unauthenticated remote code execution attempt.
To mitigate this vulnerability, immediate patching to FileBrowser version 2.63.24 or later is required, where the developers have corrected the order of operations to ensure permissions are validated before message processing begins. In environments where upgrading is not immediately feasible, administrators should implement network-level controls such as rate limiting on WebSocket connections and enforce strict payload size limits at the reverse proxy or load balancer layer. Additionally, configuring web server timeouts for long-lived WebSocket sessions can help mitigate prolonged resource consumption attacks. Monitoring heap memory usage trends and setting up alerts for abnormal spikes in memory allocation associated with specific user accounts can also aid in early detection of exploitation attempts.