CVE-2026-29188: 
NixOS vulnerability analysis and mitigation

CVE-2026-29188 is a broken access control vulnerability (IDOR / permission model bypass) in File Browser (filebrowser) that allows authenticated users with only Perm.Create=true to permanently delete arbitrary files and directories by abusing the TUS protocol DELETE endpoint, bypassing the intended Perm.Delete restriction. It affects all filebrowser versions up to and including 2.61.0, with the fix released in version 2.61.1 on March 4, 2026. The vulnerability was published to the GitHub Advisory Database on March 4, 2026, and to the NVD on March 5, 2026. The CVSS v3.1 base score is 9.1 (Critical) per the GitHub Advisory, while Feedly reports 8.1 (High) based on the NVD assessment (GitHub Advisory, Security Advisory).

The root cause is an incorrect permission check in the tusDeleteHandler function in http/tus_handlers.go (CWE-284: Improper Access Control; CWE-732: Incorrect Permission Assignment for Critical Resource). The handler gates the DELETE operation on Perm.Create instead of Perm.Delete, while the standard resourceDeleteHandler in http/resource.go correctly checks Perm.Delete. This means DELETE /api/tus/{path} and DELETE /api/resources/{path} enforce entirely different permission models for the same underlying Fs.RemoveAll() filesystem operation. An attacker only needs to initiate a TUS upload (POST to /api/tus/{path} with an Upload-Length header) to register the target path, then immediately issue a TUS DELETE request to permanently remove the file — no further interaction is required (GitHub Advisory, Patch Commit).

Successful exploitation allows an authenticated attacker to permanently delete any file or directory within their assigned scope — including files they did not create — despite having Perm.Delete=false explicitly set by an administrator. This completely undermines the intended access control model, causing high integrity and availability impact (data destruction, service disruption) with no confidentiality impact. The vulnerability is limited to the attacker's assigned filesystem scope, but in shared multi-user deployments this can result in significant data loss and denial of service for other users (GitHub Advisory).

A public proof-of-concept exploit is available in the GitHub Security Advisory, demonstrating the attack using standard curl commands. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.059% (low probability of exploitation in the next 30 days). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires valid credentials for a user account with Perm.Create=true, limiting the attack surface to authenticated users (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a filebrowser instance running version ≤ 2.61.0 with multiple users, where at least one user has Perm.Create=true and Perm.Delete=false.
2. Authenticate: Obtain an authentication token by logging in with valid credentials via the API:

   TOKEN=$(curl -s -X POST localhost:8080/api/login \
     -H "Content-Type: application/json" \
     -d '{"username":"testuser","password":"SuperSecurePassword1234"}')

3. Identify target: Determine the path of the file or directory to delete within the user's assigned scope (e.g., target.txt).
4. Initiate TUS upload: Register the target path in the TUS upload cache by sending a POST request with an Upload-Length header:

   curl -s -X POST "localhost:8080/api/tus/target.txt" \
     -H "X-Auth: $TOKEN" \
     -H "Upload-Length: 18"

   Expected response: HTTP 201 Created.
5. Issue TUS DELETE: Send a DELETE request to the TUS endpoint for the target path — the handler checks Perm.Create (which is true) instead of Perm.Delete (which is false), so the deletion proceeds:

   curl -s -X DELETE "localhost:8080/api/tus/target.txt" \
     -H "X-Auth: $TOKEN"

   Expected response: HTTP 204 No Content — file permanently deleted despite Perm.Delete=false (GitHub Advisory, Security Advisory).

• Network: Unexpected HTTP POST requests to /api/tus/{path} immediately followed by HTTP DELETE requests to the same /api/tus/{path} from the same authenticated user session; HTTP 201 responses to TUS POST followed by HTTP 204 responses to TUS DELETE for users who should not have delete rights.
• Logs: Filebrowser access logs showing a user with Perm.Delete=false successfully receiving HTTP 204 responses on DELETE /api/tus/ endpoints; absence of corresponding file upload completion (PATCH) requests between the POST and DELETE, indicating the upload was never intended to complete.
• File System: Unexpected disappearance of files or directories within a restricted user's scope that the user did not have explicit delete permissions for; missing files that were present before a TUS upload session was initiated by a restricted user.

Upgrade filebrowser to version 2.61.1 or later, which corrects the permission check in tusDeleteHandler from Perm.Create to Perm.Delete (a one-line fix in http/tus_handlers.go). For deployments unable to patch immediately, consider implementing network-level controls to restrict access to the /api/tus/ endpoint, or temporarily revoking Perm.Create for users who must not have delete capabilities. After patching, audit file access logs for suspicious TUS upload/delete activity patterns and verify that Perm.Delete restrictions are properly enforced (GitHub Advisory, Patch Commit, Release v2.61.1).

The vulnerability was reported by security researcher fg0x0 and remediated by filebrowser maintainer hacdias, who published the advisory and patch on the same day (March 4, 2026). Coverage appeared on The Hacker Wire and security aggregators including vulnerability.circl.lu and cvefeed.io shortly after disclosure. Community reaction on Bluesky noted the severity of the access control bypass in shared deployments (The Hacker Wire, GitHub Advisory).