# Attachment disclosure via summary report

IDOR in HackerOne summary report editing let attackers swap attachment_ids to read other users' uploaded PoC files by numeric ID enumeration.

- Payout: hidden
- Severity: critical
- Program: HackerOne
- Found by: xklepxn
- Disclosed: 2024-04-29
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/2442008
- Library page: https://bugbountylibrary.com/r/h1%3A2442008
- Tags: area:web domain:web impact:data-leak impact:pii-leak kind:bounty platform:hackerone sev:critical technique:recon vuln:access-control vuln:idor

**Target:** PUT /reports/{id}/summaries/{id} attachment_ids parameter
**Root cause:** Summary report edit endpoint accepted arbitrary attachment_ids without verifying ownership, unlike the submit/edit report forms which returned was_successful:false for foreign IDs.
**Steps:**
1. Create a report and a Hacker summary on it.
2. Edit the summary and attach an attacker-owned file.
3. Intercept the `PUT /reports/{id}/summaries/{id}` request and replace `attachment_ids` with the victim's numeric file id (e.g. `3155239`).
4. Render the markdown preview `{F3155239}` to read the victim's attachment.
**How found:** Submit/edit report forms rejected foreign file IDs with was_successful:false, so the researcher hunted for another endpoint handling attachments and found the summary report feature lacked the same ownership check.
**Exploitation:** Attacker enumerates sequential numeric attachment IDs and injects them into attachment_ids of a summary edit; the markdown preview then renders the victim's file, disclosing PoCs/videos.
**Escalation:** Sequential numeric IDs allow mass enumeration of all users' attachments.
**Insight:** When one endpoint correctly rejects foreign object IDs, enumerate sibling endpoints that consume the same ID type (summaries, previews, drafts) — the ownership check is often only applied on the primary path.