# SECURITY: Referencing previous Reports attachment_IDs on new Reports via Draft_Sync DELETES Attachments

Referencing another report's attachment reference_ID via draft_sync on a new report deletes the attachment from the original report.

- Payout: hidden
- Severity: medium
- Program: HackerOne
- Found by: nismo
- Disclosed: 2016-04-30
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/123615
- Library page: https://bugbountylibrary.com/r/h1%3A123615
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:medium technique:source-review vuln:access-control vuln:business-logic

**Target:** HackerOne draft_sync endpoint
**Root cause:** Attachment reference_IDs are bound to a report context but draft_sync does not verify ownership/context before moving the referenced attachment, so referencing an ID from another report relocates/deletes it from the source.
**Steps:**
1. Create a report with an attachment and file it; note the reference_ID `{Fxxxxx}`.
2. Create a new report and POST to `/security/reports/draft_sync` referencing that ID.
3. Visit `https://hackerone/security/reports/new` to see the attachment now attached to the new draft.
4. Reopen the original report: the reference_ID and attachment are deleted from it.
**How found:** Noticed inline image reference_IDs are bound to a report context and tested reusing an ID from a different report via draft_sync, observing the attachment moved/deleted.
**Exploitation:** A reporter references another of their own reports' attachment ID in a new draft via draft_sync, causing the attachment to be removed from the original report.
**Insight:** When a feature lets users reference objects by ID (inline attachments), test cross-context reuse via draft/autosave endpoints that may move or delete the referenced object rather than copy it.