Threat Intelligence Database

FileBrowser versions prior to 2.63.19 contain a vulnerability in the TUS resumable-upload PATCH endpoint where the declared Upload-Length is not enforced. This allows authenticated users to send oversized request bodies, writing arbitrary data to disk beyond the declared length. The consequence is potential exhaustion of disk space, leading to service unavailability.

File Browser versions prior to 2.63.20 contain a vulnerability where the createUserDir isolation is not enforced in proxy and hook authentication auto-provisioning paths. This flaw allows attackers with valid upstream-authenticated credentials to access and manipulate files of other users by exploiting improper server root scope assignment. The vulnerability has a high severity rating with a CVSS score of 8.8.

FileBrowser versions before 2.63.19 have a vulnerability related to case-insensitive filesystems. When self-registration is enabled with Signup and CreateUserDir, usernames differing only by letter case can map to the same physical home directory on case-insensitive filesystems like Windows/NTFS. This allows a second user to access, modify, or delete files of another user without prior authentication or victim interaction.

filebrowser versions prior to v2.63.21 do not properly canonicalize file paths before applying access control rules. This flaw allows authenticated users to bypass administrator-defined deny rules by using alternate path representations, such as case variants or backslash separators, to access files that should be denied.

filebrowser versions before 2.63.19 have a permission bypass vulnerability in the /api/resources endpoint. Specifically, the checksum query branch reads and returns file digests without enforcing the Perm.Download permission. This allows authenticated users without download rights to obtain content hashes of files within their scope, potentially confirming file contents or detecting changes. This issue is a partial fix of a previous vulnerability (CVE-2026-35606) and does not bypass scope or path authorization controls.

filebrowser versions prior to 2.63.19 have a vulnerability in the TUS upload cache eviction mechanism that allows authenticated users with Create permission to delete arbitrary files outside their allowed scope by exploiting a symlink attack during the cache TTL window.

File Browser versions 2.50.0 through 2.63.21 contain a vulnerability where JWT expiration is not validated if proxy authentication is configured with a non-default logout page. This allows attackers with previously valid tokens to access protected and administrative routes indefinitely and to renew expired tokens via the renewal endpoint.

File Browser versions prior to 2.63.22 have a vulnerability where access rules for descendant files and directories are not properly validated during recursive copy, rename, and delete operations. This allows authenticated users to bypass path-based access controls by manipulating allowed parent directories to affect denied files, compromising confidentiality and integrity.

### Summary The `subtitlesHandler` endpoint (`GET /api/media/subtitles`) accepts two user-controlled query parameters: `path` and `name`, both of which are used in filesystem operations without sanitization, creating two independent path traversal vectors. The primary vector is the `path` parameter: it is passed directly to `idx.GetRealPath()` without calling `SanitizeUserPath()`, allowing an attacker to escape the storage root and set `parentDir` to any directory on the host. No existing anchor file is required. The secondary vector is the `name` parameter: it is joined with `parentDir` via `filepath.Join(parentDir, name)` without stripping directory components, allowing traversal relative to any resolved `parentDir`. Any authenticated user (regardless of role or permissions) can exploit either vector to read any text file readable by the server process, including `/etc/passwd`, SSH keys, database credentials, and JWT signing keys. ### Details **1. `path` parameter lacks `SanitizeUserPath()` — primary vector (`http/media.go:54`)** ```go userscope, err := d.user.GetScopeForSourceName(source) // ... realPath, _, err := idx.GetRealPath(userscope, path) // path is raw user input, no sanitization // ... parentDir := filepath.Dir(realPath) // line 59: attacker controls this directory ``` `SanitizeUserPath()` explicitly rejects `..` segments: ```go func SanitizeUserPath(userPath string) (string, error) { // ... for _, segment := range segments { if segment == ".." { return "", fmt.Errorf("invalid path: path traversal detected") } } // ... } ``` Every other handler in the codebase calls `SanitizeUserPath()` before `GetRealPath()`. This handler skips it, so `path=../../etc/passwd` resolves `parentDir` to `/etc`, with no anchor file required. **2. `name` parameter used directly in `filepath.Join` — secondary vector (`http/media.go:63`)** ```go name := r.URL.Query().Get("name") // line 37 — raw user input // ... content, err = utils.GetSubtitleSidecarContent( filepath.Join(parentDir, name)) // line 63 — TRAVERSAL ``` `filepath.Join(parentDir, "../../etc/passwd")` resolves the `..` components, escaping `parentDir`. This vector requires a valid file in scope as the `path` anchor. **3. `GetSubtitleSidecarContent` reads and returns file contents (`common/utils/media.go:17-43`)** ```go func GetSubtitleSidecarContent(subtitlePath string) (string, error) { info, err := os.Stat(subtitlePath) // follows the traversed path // size check: < 50MB isText, err := IsTextFile(subtitlePath) // checks UTF-8 validity content, err := os.ReadFile(subtitlePath) // reads and returns content return string(content), nil } ``` The only constraint is that the target file must be UTF-8 valid and under 50MB. Binary files silently return an empty string. **4. Endpoint is behind `withUser` but requires no special permissions** ```go // httpRouter.go api.HandleFunc("GET /media/subtitles", withUser(subtitlesHandler)) ``` Any authenticated user can access this endpoint: no admin, modify, share, or download permission is required. ### PoC **Vector 1: `path` traversal (no anchor file needed):** ```bash docker run -d --name filebrowser-q-lab -p 18080:80 gtstef/filebrowser:latest && sleep 3 TOKEN=$(curl -s -X POST "http://localhost:18080/api/auth/login?username=admin" -H "X-Password: admin" | tr -d '"') curl "http://localhost:18080/api/media/subtitles?path=../../etc/passwd&source=srv&name=passwd&embedded=false&auth=$TOKEN" ``` **Expected output:** `/etc/passwd` contents with HTTP 200. **Vector 2: `name` traversal (anchor file required):** ```bash mkdir -p /tmp/fbq-srv && echo "dummy" > /tmp/fbq-srv/poc.txt docker run -d --name filebrowser-q-lab2 -p 18081:80 -v /tmp/fbq-srv:/srv gtstef/filebrowser:latest && sleep 3 TOKEN=$(curl -s -X POST "http://localhost:18081/api/auth/login?username=admin" -H "X-Password: admin" | tr -d '"') curl "http://localhost:18081/api/media/subtitles?path=/poc.txt&source=srv&name=../../etc/passwd&embedded=false&auth=$TOKEN" ``` **Expected output:** `/etc/passwd` contents with HTTP 200. ### Impact - **Arbitrary file read**: Any authenticated user can read any text file on the host filesystem that the server process has read permission for. - **No anchor file required**: The `path` vector works on a default install with an empty storage root, so no existing file in scope is needed. - **Scope bypass**: Scoped users (restricted to a subdirectory) can escape their scope via either vector and access files belonging to other users or the host system. - **Credential exposure**: `/etc/passwd`, `/etc/shadow` (if running as root), SSH private keys, application configuration files with database passwords, API keys, and JWT signing secrets. - **Privilege escalation**: Reading the JWT signing key from the database or config file enables forging admin tokens. - **No special permissions required**: The endpoint only requires basic authenti

FileBrowser Quantum is a free, self-hosted, web-based file manager. Prior to version 1.3.2-beta, the `/api/auth/login` authentication endpoint does not execute in constant time. When a non-existent username is supplied, the server returns a `401`/`403` response almost immediately. When a valid username is provided, the server performs a bcrypt password comparison, causing a measurable delay in the response time. Version 1.3.2-beta patches the issue.