Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/gtsteffaniak/filebrowser/backend < 0.0.0-20260814233832-4126edeb07a0
Fixed in
0.0.0-20260814233832-4126edeb07a0· Vendor fix available
Issue
File read paths resolve symbolic links with `filepath.EvalSymlinks` and then operate on the resolved target without re-checking that the target still lies inside the user's source/scope. A symlink located inside a user's accessible directory that points outside the scope (for example to `/etc/passwd`, another tenant's directory, SSH keys, or container secrets) is followed transparently, and its contents are served through the normal download, preview, media, and OnlyOffice endpoints. Any authenticated user with download access can read files anywhere the server process can, whenever such a symlink is reachable in their scope. The same symlink-following read path is used by the public share endpoints, which are authorized only by a share hash and not by any account, so when a public share exposes a directory that contains such a symlink, an unauthenticated attacker holding only the share link reads files outside the scope with no credential. Details **1. Symlink…
Recommended action: Upgrade to 0.0.0-20260814233832-4126edeb07a0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gtsteffaniak/filebrowser/backend < 0.0.0-20260608182036-f3f4bbe80cb5
Fixed in
0.0.0-20260608182036-f3f4bbe80cb5· Vendor fix available
Issue
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…
Recommended action: Upgrade to 0.0.0-20260608182036-f3f4bbe80cb5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gtsteffaniak/filebrowser/backend < 0.0.0-20260518193514-28e9b81e438e
Fixed in
0.0.0-20260518193514-28e9b81e438e· Vendor fix available
Issue
publicPatchHandler in backend/http/public.go joins user-controlled fromPath and toPath body fields with the trusted d.share.Path BEFORE the downstream sanitizer runs. Because filepath.Join collapses .. segments during the join, the sanitizer in resourcePatchHandler never sees the traversal and the move/copy/rename operates on a path outside the shared directory. The same root-cause pattern was patched for the bulk DELETE endpoint as CVE-2026-44542 (GHSA-fwj3-42wh-8673), but the PATCH handler with the identical pattern was not updated. A public share link with AllowModify=true is sufficient to exploit this. Anyone holding such a link can move, copy, or rename arbitrary files within the share owner's source root. Verified on commit 869b640 (HEAD of main as of 2026-05-07). Details In backend/http/public.go the public PATCH handler accepts a JSON body with items[].fromPath and items[].toPath from the client, then prepends the share path before delegating to resourcePatchHandler:…
Recommended action: Upgrade to 0.0.0-20260518193514-28e9b81e438e (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gtsteffaniak/filebrowser/backend < 0.0.0-20260514154726-1802e1281135
Fixed in
0.0.0-20260514154726-1802e1281135· Vendor fix available
Issue
Impact Some sensitive info -- such as source and path can get exposed. Patches Update to the latest version Workarounds no
Recommended action: Upgrade to 0.0.0-20260514154726-1802e1281135 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gtsteffaniak/filebrowser/backend < 0.0.0-20260317230626-af08800667b8
Fixed in
0.0.0-20260317230626-af08800667b8· Vendor fix available
Issue
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. Details The vulnerability exists in the Auth function of JSONAuth in auth/json.go (lines 45–52). The function performs a database lookup for the user prior to performing any password validation. If the username is not found, the function returns an error immediately. If the username is found, the function calls CheckPwd, which executes the bcrypt hash comparison. Because bcrypt is intentionally computationally expensive, this introduces a measurable delay in the response time. As a result, an attacker can distinguish valid usernames from invalid ones by measuring the authentication response times. In testing, responses for valid usernames consistently required…
Recommended action: Upgrade to 0.0.0-20260317230626-af08800667b8 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gtsteffaniak/filebrowser/backend < 0.0.0-20260307130210-09713b32a5f6
Fixed in
0.0.0-20260307130210-09713b32a5f6· Vendor fix available
Issue
The remediation for CVE-2026-27611 appears incomplete. Password protected shares still disclose tokenized downloadURL via /public/api/share/info in docker image gtstef/filebrowser:1.3.1-webdav-2. Details The issue stems from two flaws: 1. Tokenized download URLs are written into the persistent share model 2. The public endpoint: Since Token is set for password-protected shares, and getShareURL(..., true, token) embeds it as a query parameter, the public API discloses a valid bearer download capability. The previous patch removed token generation in one handler but did not address the persisted DownloadURL values/Public reflection of existing DownloadURL PoC 1. Create a password protected share as an authenticated user 2. Copy the public share URL (the clipboard WITHOUT an arrow) http://yourdomain/public/share/yoursharedhash Example: http://yourdomain/public/share/2EBGbXgXg5dpw-nK0RG6vw 3. Query the public share endpoint via curl request: curl…
Recommended action: Upgrade to 0.0.0-20260307130210-09713b32a5f6 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/gtsteffaniak/filebrowser/backend < 0.0.0-20260221163904-dbcfba993b85
Fixed in
0.0.0-20260221163904-dbcfba993b85· Vendor fix available
Issue
When users share password-protected files, the recipient can completely bypass the password and still download the file. Details This happens because the API returns a direct download link in the details of the share, which is accessible to anyone with JUST THE SHARE LINK, even without the password. PoC 1. As an authenticated user, create a share for a file, with a password specified in "Optional password" (make sure to allow anonymous access as the PoC doesn't explain how to do this on a share that requires login, but it is also possible to do on a share that requires login, with some small tweaks to the API request) 2. Copy the first link (the clipboard WITHOUT an arrow) because the second one just completely skips the password without any effort required, which was mentioned in another vulnerability (https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3v48-283x-f2w4) Now, the link that was copied should look like:…
Recommended action: Upgrade to 0.0.0-20260221163904-dbcfba993b85 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.