# User with read-only access to a share can gain write access to sub-folders in the share

Read-only share recipient could PUT permissions=15 on their own link share, gaining write/delete access to sub-folders they were only granted read access to.

- Payout: hidden
- Severity: medium
- Program: Nextcloud
- Found by: phil-davis
- Disclosed: 2020-03-01
- CVE: CVE-2019-15621
- Write-up quality: 7/10
- Original: https://hackerone.com/reports/619484
- Library page: https://bugbountylibrary.com/r/h1%3A619484
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:medium tech:rest technique:source-review vuln:access-control vuln:business-logic vuln:privilege-escalation

**Target:** Nextcloud OCS sharing API (files_sharing)
**Root cause:** The share-update endpoint did not validate that the requested permissions were a subset of the permissions the caller actually holds on the shared node, so a read-only recipient could raise their own link share to full permissions.
**Steps:**
1. user0 creates /test and /test/sub with /test/sub/file.txt
2. user0 shares /test with user1 with permissions 17 (read+share)
3. user1 creates a link share of /test/sub (permissions 1, read-only)
4. user1 sends `curl --user user1:user1 "http://host/ocs/v1.php/apps/files_sharing/api/v1/shares/3" -H "OCS-APIRequest: true" -X PUT --data 'permissions=15'`
5. user1 opens the link `/index.php/s/t9dfm6K57yo6a9r` and can now create/change/delete files
**How found:** Noticed that a link share created by a read-only recipient could be updated via the sharing API beyond the creator's own permission level; tested by bumping permissions to 15 and confirming write via the public link.
**Exploitation:** Attacker with only read+share on a folder creates a public link share of a sub-folder, then PUTs permissions=15 to the OCS share API to upgrade it to read-write-delete, and uses the public link to modify/delete files in the supposedly read-only tree.
**Escalation:** Single compromised or malicious user can alter documents visible to everyone in an org-wide read-only share.
**Insight:** When testing share systems, check whether the share-update endpoint enforces that new permissions are a subset of the caller's effective permissions on the node, not just ownership of the share object.