# User can delete data in shared folders he's not autorized to access

Low-privileged user bypassed denied folder permissions by renaming a synced folder to the hidden folder's name, overwriting and destroying its contents.

- Payout: hidden
- Severity: medium
- Program: Nextcloud
- Found by: jlord87
- Disclosed: 2020-04-10
- CVE: CVE-2020-8153
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/642515
- Library page: https://bugbountylibrary.com/r/h1%3A642515
- Tags: area:os domain:desktop domain:web impact:data-leak impact:integrity kind:bounty platform:hackerone sev:medium tech:rest vuln:access-control vuln:business-logic

**Target:** Nextcloud desktop sync client and group folder sharing
**Root cause:** The sync client's rename operation is not re-validated against the server-side advanced folder permissions, so a locally renamed folder is pushed to a path the user is denied access to, overwriting the existing hidden folder.
**Steps:**
1. Create group folder TEST shared with admin group and test group with advanced permission flag
2. Create folders `visible` and `invisible` inside; put `test.txt` in `invisible`
3. Set advanced permissions on `invisible` to deny all for test group (read/write/share/create/delete)
4. Log in as test user: `invisible` is hidden; creating a folder named `invisible` errors
5. Sync external share to desktop client (2.5.2 on win7); only `visible` syncs
6. Create folder `temp` with `test2.txt` inside; let it sync
7. Rename `temp` to `invisible` locally
8. Client syncs the rename, overwriting the original `invisible` folder and its contents
**How found:** Tester probed permission enforcement: confirmed the denied folder was hidden and direct creation of a same-named folder was blocked, then hypothesized the sync client's rename path might not enforce the same check and tested it.
**Exploitation:** A low-privileged group member uses the desktop sync client to rename an allowed synced folder to the name of a permission-denied folder; the client pushes the rename to the server, overwriting the protected folder and destroying its data.
**Insight:** When a server blocks creating a resource at a denied path, test alternate write primitives that reach the same path—rename/move via sync clients, WebDAV MOVE, or copy—since permission checks are often applied per-operation and rename may skip the target-path ACL.