# Delete permission can be added on reshare

A reshare recipient could add delete permission to a share they only had read+share on, letting them or a group delete the original owner's files.

- Payout: hidden
- Severity: low
- Program: Nextcloud
- Found by: phil-davis
- Disclosed: 2019-09-03
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/633245
- Library page: https://bugbountylibrary.com/r/h1%3A633245
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:low tech:rest vuln:access-control vuln:business-logic vuln:privilege-escalation

**Target:** Nextcloud files sharing OCS API / WebDAV
**Root cause:** View.php ORs PERMISSION_DELETE onto the share root for MoveableMount so recipients can unshare; this implied delete is passed on when resharing, allowing a recipient to grant delete they never had.
**Steps:**
1. user0 creates /test/file.txt and shares /test with user1 with permissions 17 (read+share).
2. user1 reshares /test to user2 via OCS API with `permissions=25` (read+reshare+delete).
3. user2 deletes the file: `curl --user user2:user2 .../remote.php/dav/files/user2/test/file.txt -X DELETE`.
4. Alternatively user1 shares with a group they belong to adding delete, gaining delete on the folder.
**How found:** Reading View.php line 1389 where MoveableMount share roots get PERMISSION_DELETE ORed in for unshare purposes, then testing whether that implied delete propagates through a reshare.
**Exploitation:** A recipient of a read+share share reshares it specifying delete permission (25) to another user or a group they belong to, then deletes files in the original owner's folder via WebDAV DELETE or web UI.
**Escalation:** Sharing to a group the attacker is already a member of grants the attacker themselves delete access to the folder contents.
**Insight:** When a platform adds implied permissions to a share root for UX (e.g. unshare), test whether those implied bits are re-validated or blindly forwarded when the share is reshared or shared to a group.