CVE-2026-90927: filebrowser WebSocket DOS Vulnerability

CVE-2026-90927 Overview

CVE-2026-90927 is a denial-of-service vulnerability in filebrowser through version 2.63.23. The flaw resides in the /api/command WebSocket handler, which fails to enforce a message size limit before performing permission checks. Authenticated users can send arbitrarily large WebSocket messages that the server buffers into heap memory. This exhausts server memory and crashes the process. The issue is classified under CWE-400: Uncontrolled Resource Consumption. Exploitation succeeds regardless of the EnableExec setting or whether the account holds the Execute permission.

Critical Impact
Any authenticated filebrowser user can crash the server by sending oversized WebSocket messages to /api/command, causing full service disruption.

Affected Products

filebrowser through version 2.63.23
Deployments exposing the /api/command WebSocket endpoint
Any filebrowser instance with authenticated user accounts, irrespective of EnableExec configuration

Discovery Timeline

2026-09-14 - CVE-2026-90927 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-90927

Vulnerability Analysis

filebrowser exposes a WebSocket endpoint at /api/command used to stream command execution output to clients. The handler upgrades the HTTP connection to WebSocket, then reads incoming frames into memory before evaluating whether the calling user is authorized to execute commands. Because no upper bound is placed on the read buffer, an attacker controls how much memory the server allocates per message. Sending a single very large frame, or a chain of continuation frames, forces the Go runtime to allocate heap memory until the process is killed by the operating system or becomes unresponsive.

The permission logic that would ordinarily reject non-privileged callers runs after the message has already been buffered. As a result, disabling command execution via EnableExec=false or withholding the Execute permission does not prevent the attack.

Root Cause

The root cause is missing input size validation on WebSocket reads in the /api/command handler. The code path buffers the entire client message before checking authorization, violating the principle of validating untrusted input at the earliest boundary. This is a classic uncontrolled resource consumption defect [CWE-400].

Attack Vector

The attack requires network access to the filebrowser instance and any valid low-privilege account. The attacker authenticates, opens a WebSocket connection to /api/command, and transmits an oversized payload. The server allocates memory proportional to the payload size, exhausting available heap and terminating the process. Repeated connections from one or more sessions can keep the service offline. No user interaction is required beyond the attacker's own session.

Refer to the GitHub Security Advisory GHSA-39cx-23x9-5c8p and the VulnCheck FileBrowser DoS Advisory for additional technical context.

Detection Methods for CVE-2026-90927

Indicators of Compromise

Sudden spikes in the filebrowser process resident set size (RSS) followed by out-of-memory (OOM) termination
WebSocket upgrade requests to /api/command from low-privilege user accounts immediately preceding a crash
Repeated filebrowser process restarts logged by the service manager (systemd, container orchestrator)
Unusually large inbound frames on WebSocket connections to the filebrowser host

Detection Strategies

Monitor filebrowser memory consumption and alert when RSS exceeds a baseline threshold or grows sharply over a short interval
Log and inspect HTTP upgrade requests to /api/command, correlating source IP and authenticated user with subsequent memory events
Deploy a reverse proxy in front of filebrowser and cap WebSocket message size at the proxy layer to generate rejection logs for oversized frames

Monitoring Recommendations

Ingest filebrowser access logs and host process telemetry into a central analytics platform for correlation across memory spikes, restarts, and authentication events
Track per-user WebSocket connection counts and byte volumes to identify abusive sessions
Alert on OOM kill events referencing the filebrowser binary in kernel logs (dmesg, /var/log/messages)

How to Mitigate CVE-2026-90927

Immediate Actions Required

Upgrade filebrowser to a release above 2.63.23 once a fixed version is published by the maintainers
Restrict network exposure of filebrowser to trusted networks or VPN clients until patched
Review and disable unused local accounts to reduce the pool of credentials that can trigger the flaw
Enforce rate limits on authenticated sessions at a reverse proxy in front of filebrowser

Patch Information

Refer to the GitHub Security Advisory GHSA-39cx-23x9-5c8p for the authoritative fix status and release notes. The advisory tracks affected versions and any published patch that enforces a maximum WebSocket message size before authorization checks.

Workarounds

Place filebrowser behind a reverse proxy such as nginx, Caddy, or Traefik and configure a strict maximum WebSocket frame size (for example, proxy_max_temp_file_size and client_max_body_size in nginx, plus WebSocket-specific frame limits)
Constrain the filebrowser process with cgroup memory limits so an OOM event impacts only the container rather than the host
Block direct external access to /api/command at the network edge if command execution features are not required

bash

# Configuration example: nginx reverse proxy limiting request and WebSocket sizes
server {
    listen 443 ssl;
    server_name files.example.com;

    client_max_body_size 1m;

    location /api/command {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
        # Reject oversized bodies before they reach filebrowser
        client_max_body_size 64k;
    }

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