# Nextcloud Deck : Possibility for anyone to add a stack with existing tasks on anyone's board

IDOR in Nextcloud Deck lets any unprivileged user move a stack with its tasks onto another user's board by tampering with the boardId parameter.

- Payout: hidden
- Severity: medium
- Program: Nextcloud
- Found by: supr4s
- Disclosed: 2022-05-20
- CVE: CVE-2022-29159
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/1450117
- Library page: https://bugbountylibrary.com/r/h1%3A1450117
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:medium tech:php technique:source-review vuln:access-control vuln:idor

**Target:** Deck app REST endpoint PUT /apps/deck/stacks/{id}
**Root cause:** The stack update endpoint trusts the client-supplied boardId and does not verify the caller has write access to the target board, only to the stack.
**Steps:**
1. Create users A and B, each with their own board; note both boardId values.
2. As user A, rename a stack via `PUT /apps/deck/stacks/31` with body `{"title":"IDOR","boardId":14,...}`.
3. Intercept and change `boardId` to victim B's board id, replay request.
4. Server returns 200 with the stack now bound to victim's boardId.
5. Log in as B: the stack and all its tasks/images/labels appear on B's board.
**How found:** Researcher inspected the stack-rename PUT request, noticed boardId was client-controlled, and hypothesized the server would not re-check board ownership.
**Exploitation:** Attacker with any account renames their own stack while swapping boardId to the victim's board, transferring the stack and its tasks into the victim's board; brute-forcing boardId 1..1000 lets them target all boards, and deleting the injected stack on the victim side also removes it for the attacker.
**Escalation:** Brute-force sequential boardId values to inject stacks into every user's board; inject many stacks to clutter/DoS victim boards.
**Insight:** On object-update endpoints, look for foreign-key fields (boardId, parentId) in the body that the server echoes back without re-authorizing against the new parent — moving an object between parents is a classic IDOR that bypasses per-object ACLs.