File Browser before v2.63.22 fails to validate access rules for descendants during recursive copy, rename, and delete operations, allowing authenticated users to bypass path-based access controls. Attackers can copy, rename, or delete denied files by operating on their allowed parent directory, defeating rule-based isolation for confidentiality and integrity.

File Browser versions from 2.50.0 through 2.63.21 fail to validate JWT expiration when proxy authentication is configured with a non-default logout page. Attackers with a previously valid token can access protected routes and administrative endpoints indefinitely, and exchange expired tokens for fresh ones via the renewal endpoint.

filebrowser through 2.63.16 fails to properly restrict scope and permissions when self-signup is enabled with default CreateUserDir setting. Unauthenticated attackers can register accounts that inherit the server root scope with full create, modify, delete, rename, share, and download permissions, allowing unrestricted access to all files.

filebrowser versions before 2.63.19 contain an out-of-scope file deletion vulnerability in the TUS upload cache eviction mechanism that allows authenticated users with only Create permission to delete arbitrary files outside their scope. Attackers can swap an ancestor directory with a symlink during the cache TTL window to redirect the raw os.Remove call to an out-of-scope target, bypassing ScopedFs scope guards and Perm.Delete checks.

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.63.17, File Browser builds new user scopes from usernames passed through cleanUsername() when Signup=true and CreateUserDir=true, but the many-to-one normalization can collapse usernames such as team/one, team one, and team-one to the same home directory without checking whether the resulting scope is already taken, allowing a second registrant to gain full read and write access to another user's files. This issue is fixed in version 2.63.17.

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. From 2.63.6 to 2.63.16, File Browser's archive builder uses strings.ReplaceAll(nameInArchive, "\", "/"), which turns a POSIX filename such as ..\..\evil.sh into the archive entry ../../evil.sh, allowing a user with upload permission to plant a backslash-named file that escapes the extraction directory when another user downloads and extracts the generated zip or tar archive. This issue is fixed in version 2.63.17.

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Prior to 2.33.8, when a shell interpreter is configured (e.g. /bin/sh -c), the command allowlist can be bypassed through shell metacharacters. The allowlist validates only the first token of user input, but the entire raw string is handed to the shell — semicolons, pipes, backticks, and $() all work to chain arbitrary commands after a permitted one. This vulnerability is fixed in 2.33.8.

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. In versions 2.61.2 and below, the TUS resumable upload handler parses the Upload-Length header as a signed 64-bit integer without validating that the value is non-negative, allowing an authenticated user to supply a negative value that instantly satisfies the upload completion condition upon the first PATCH request. This causes the server to fire after_upload exec hooks with empty or partial files, enabling an attacker to repeatedly trigger any configured hook with arbitrary filenames and zero bytes written. The impact ranges from DoS through expensive processing hooks, to command injection amplification when combined with malicious filenames, to abuse of upload-driven workflows like S3 ingestion or database inserts. Even without exec hooks enabled, the negative Upload-Length creates inconsistent cache entries where files are marked complete but contain no data. All deployments using the TUS upload endpoint (/api/tus) are affected, with the enableExec flag escalating the impact from cache inconsistency to remote command execution. At the time of publication, no patch or mitigation was available to address this issue.

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Versions 2.61.0 and below contain a permission enforcement bypass which allows users who are denied download privileges (perm.download = false) but granted share privileges (perm.share = true) to exfiltrate file content by creating public share links. While the direct raw download endpoint (/api/raw/) correctly enforces the download permission, the share creation endpoint only checks Perm.Share, and the public download handler (/api/public/dl/<hash>) serves file content without verifying that the original file owner has download permission. This means any authenticated user with share access can circumvent download restrictions by sharing a file and then retrieving it via the unauthenticated public download URL. The vulnerability undermines data-loss prevention and role-separation policies, as restricted users can publicly distribute files they are explicitly blocked from downloading directly. This issue has been fixed in version 2.62.0.

File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Versions 2.61.2 and below are vulnerable to Path Traversal through the resourcePatchHandler (http/resource.go). The destination path in resourcePatchHandler is validated against access rules before being cleaned/normalized, while the actual file operation calls path.Clean() afterward—resolving .. sequences into a different effective path. This allows an authenticated user with Create or Rename permissions to bypass administrator-configured deny rules (both prefix-based and regex-based) by injecting .. sequences in the destination parameter of a PATCH request. As a result, the user can write or move files into any deny-rule-protected path within their scope. However, this cannot be used to escape the user's BasePathFs scope or read from restricted paths. This issue has been fixed in version 2.62.0.