# Program Member Could Duplicate Report To A Non Related Program Original Report

HackerOne program members could set original_report_id in /reports/bulk to any report ID, including unrelated or private reports, marking their report as duplicate of another program's report.

- Payout: hidden
- Severity: high
- Program: HackerOne
- Found by: v0id1
- Disclosed: 2024-06-19
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/2513082
- Library page: https://bugbountylibrary.com/r/h1%3A2513082
- Tags: area:web domain:web impact:integrity kind:bounty platform:hackerone sev:high technique:param-pollution vuln:access-control vuln:idor

**Target:** hackerone.com /reports/bulk endpoint
**Root cause:** The /reports/bulk endpoint trusted the client-supplied original_report_id without verifying the target report belongs to the same program or is accessible to the acting program member.
**Steps:**
1. Create a sandbox program
2. On a report, choose closed as duplicate and select another report from your program
3. Intercept the request to `/reports/bulk`
4. Change `original_report_id` to an unrelated report ID, e.g. `2279010` (PortSwigger report)
5. Observe the report is marked duplicate of the foreign report
6. Repeat with a private report ID (e.g. `2441985`) accessible to the actor to link to private reports
**How found:** Researcher noticed the duplicate flow sends original_report_id client-side and hypothesized the server did not scope it to the program; tested by swapping in a known public report ID and then a private report ID.
**Exploitation:** A program member intercepts the bulk duplicate request and substitutes original_report_id with any report ID (public hacktivity or private), causing the platform to record a duplicate relationship to a report outside their program.
**Insight:** Bulk/action endpoints that accept object IDs (like original_report_id) often skip the same authorization checks as the single-item UI path; intercept the bulk request and swap IDs to foreign/private objects.