# An attacker can submit arbitrary projects to their service accounts and obtain full information on projects of other users.

IDOR in LinkedIn Request Services let an attacker iterate integer project IDs, read other users' confidential project details, and submit their own proposals to the project owner.

- Payout: hidden
- Severity: high
- Program: LinkedIn
- Found by: marvelmaniac
- Disclosed: 2024-03-12
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/2291999
- Library page: https://bugbountylibrary.com/r/h1%3A2291999
- Tags: area:web domain:api domain:web impact:data-leak impact:integrity kind:bounty platform:hackerone sev:high tech:rest vuln:access-control vuln:business-logic vuln:idor

**Target:** Voyager marketplace engagement API
**Root cause:** The createEngagementV2 endpoint accepted an arbitrary projectUrn without verifying the caller owned or was authorized for that project, so integer project IDs could be iterated to reference other users' confidential projects.
**Steps:**
1. Identify the Request Services feature and its engagement creation endpoint.
2. Send `POST /voyager/api/voyagerMarketplacesDashServiceMarketplaceEngagement?action=createEngagementV2&decorationId=com.linkedin.voyager.dash.deco.marketplaces.CreateEngagementResponse-4` with body `{"projectUrn":"urn:li:fsd_marketplaceProject:(<PROJECT-ID>,SERVICE_MARKETPLACE)","providerProfileUrn":"urn:li:fsd_profile:<ATTACKER--SERVICE-ACCOUNT-ID>"}`.
3. Iterate integer PROJECT-ID values to reference projects belonging to other users.
4. Observe returned project details and submit own proposal to the victim project owner.
**How found:** Researcher noticed ProjectIDs are sequential integers in the Request Services feature and tested whether the engagement endpoint enforced ownership on the projectUrn, finding it did not.
**Exploitation:** Attacker with a service account iterates integer project IDs in the projectUrn parameter of createEngagementV2, obtaining confidential project details of other users and submitting their own proposals to those victims, gaining work without authorization. No user interaction required.
**Insight:** Marketplace/engagement endpoints that take a resource URN as a body parameter often skip ownership checks that the read path enforces; test whether you can create an engagement against another user's object by iterating its integer ID.

## Proof of concept (copied exactly from the original report)

**POST request creating engagement with arbitrary projectUrn**

```
POST /voyager/api/voyagerMarketplacesDashServiceMarketplaceEngagement?action=createEngagementV2&decorationId=com.linkedin.voyager.dash.deco.marketplaces.CreateEngagementResponse-4
Host: www.linkedin.com
.
.
.

{"projectUrn":"urn:li:fsd_marketplaceProject:(<PROJECT-ID>,SERVICE_MARKETPLACE)","providerProfileUrn":"urn:li:fsd_profile:<ATTACKER--SERVICE-ACCOUNT-ID>"}
```