filebrowser from version 2.24.0 contains a race condition in the TUS upload handler that allows authenticated users to write past the declared Upload-Length by sending concurrent PATCH requests. Attackers can send multiple simultaneous PATCH requests at the same offset to bypass length validation, resulting in files that exceed their declared size and triggering completion hooks for oversized uploads.

File Browser versions from 2.63.6 through 2.63.23 fail to clean up public share links when a privileged user deletes another user's shared file. Attackers can access the surviving share link to retrieve new unrelated content uploaded to the same path without authentication.

filebrowser through 2.63.23 fails to validate named pipes in directory archive and public download handlers, allowing attackers to trigger blocking open syscalls. Authenticated users or anonymous visitors with public share links can repeatedly request archives containing named pipes to pin server goroutines and exhaust connection resources.

filebrowser through 2.63.23 does not remove share records when a shared file is renamed (only deletion triggers share cleanup). The share record is keyed by path, so it survives the rename and remains dormant (returning 404 while the path is empty). When any new, unrelated file later appears at the original shared path — via re-upload, another user with create permission, or a hook — the stale public share link serves that new file under the original link's password and expiry settings, unexpectedly exposing it.

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.17, the Link storage struct is serialized directly by sharePostHandler, shareListHandler, and shareGetsHandler through renderJSON, causing POST /api/share/{path} and GET /api/shares to expose password_hash and the bypass token, while an administrator can retrieve these secrets for every user's shares, enabling offline password cracking and direct access to protected shares. This issue is fixed in version 2.63.17.

filebrowser before 2.63.19 contains a permission bypass in the /api/resources endpoint. The checksum (?checksum=) branch of resourceGetHandler reads the entire file to compute a digest and returns it without performing a Perm.Download check (unlike the sibling raw, preview, and subtitle paths). As a result, an authenticated user provisioned with Perm.Download=false can obtain a content-hash oracle for any same-scope file (md5/sha1/sha256/sha512), enabling confirmation of known/guessed content, change detection, and offline brute-force of low-entropy files. This is an incomplete fix of CVE-2026-35606; it bypasses only the Download permission and does not defeat scope/path authorization.

FileBrowser versions before 2.63.19 fail to enforce the declared Upload-Length in the TUS resumable-upload PATCH endpoint, allowing authenticated users to write arbitrary data to disk. Attackers can send oversized request bodies that exceed the declared upload length to exhaust available disk space and cause service unavailability.

File Browser versions before 2.63.20 fail to honor the createUserDir isolation in proxy and hook authentication auto-provisioning paths. Attackers with valid upstream-authenticated credentials can read, modify, delete, and share files belonging to other users by exploiting the server root scope assignment.

filebrowser versions before v2.63.21 fail to canonicalize paths before evaluating access rules, allowing authenticated users to bypass administrator-defined deny rules using case-variant or backslash-separated paths. Attackers can request files with alternate path representations that match no rule but resolve to the same filesystem object, gaining unauthorized access to denied files within their scope.

FileBrowser before 2.63.19 does not account for case-insensitive filesystems when checking home directory ownership during self-registration. When Signup and CreateUserDir are enabled and FileBrowser's root is on a case-insensitive filesystem (confirmed on Windows/NTFS), two self-registered usernames that differ only in letter case (e.g., CaseVictim and casevictim) are stored as distinct accounts but resolve to the same physical home directory, because the scope-ownership check compares the persisted scope as an exact case-sensitive string. A second registrant can therefore read, overwrite, and delete another account's files through authenticated HTTP endpoints, without needing an existing account or victim interaction.