Full Report
LinkedIn is a social media site for business professionals. An entity on a website is commonly referenced by an identifier. On LinkedIn, this could be a post, picture or many other things. When using IDs, it is important to validate permissions on these IDs. Otherwise, security problems can occur. In the case of LinkedIn, they were not validated the ID of posts upon deleting them. Practically, this means that any user could have deleted any other users posts. Considering this could be used by competitor businesses or governments to quite people, this is a major problem. It led to 10K in bug bounty money for a simple IDOR.
Analysis Summary
Based on the context provided, this summary focuses on the vulnerability described regarding LinkedIn's post deletion mechanism. Since the input article snippet does not contain a specific CVE ID, CVSS score, or official patch details, these fields will be marked as "Not Available" or inferred based on the technical description.
# Vulnerability: Insecure Direct Object Reference (IDOR) in LinkedIn Post Deletion
## CVE Details
- CVE ID: Not Available (Likely a zero-day reported via Bug Bounty)
- CVSS Score: High (Inferred, given the potential for mass deletion of content)
- CWE: CWE-284: Improper Access Control
## Affected Systems
- Products: LinkedIn platform (Web application)
- Versions: Not specified; assumed to be the version active when the flaw was discovered.
- Configurations: System handling post deletion requests where the ID of the post was directly used without proper authorization checks.
## Vulnerability Description
The vulnerability existed due to a failure to validate ownership or authorization permissions when processing requests to delete posts (entities referenced by an ID). Specifically, when a user initiated a post deletion request, the server accepted the provided Post ID without adequately verifying if the requesting user was the rightful owner of that post. This allows any authenticated user to use the delete endpoint with an arbitrary Post ID to delete content belonging to other users.
## Exploitation
- Status: Could be exploited (Confirmed by the $10K bug bounty payment suggests active reporting/proof of concept existed).
- Complexity: Low (Authentication is likely required, but exploitation logic is minimal—sending a single unauthorized API request).
- Attack Vector: Network (Via standard web/API interaction).
## Impact
- Confidentiality: Low (Primarily affects integrity, though deleting content removes an element of confidentiality assurance).
- Integrity: **High** (Any user can delete *any* other user's posts, potentially leading to mass content destruction).
- Availability: High (If exploited at scale, posts/content could be rendered unavailable via deletion).
## Remediation
### Patches
- Patch Status: Assumed fixed following the bug bounty disclosure. (Specific patch version/date not provided in the source material.)
- Action: Developers must ensure that every request utilizing an entity ID (like a Post ID) for modification or deletion is immediately preceded by a check confirming the authenticated session user has the necessary authorization rights over that specific resource.
### Workarounds
- None documented, as this is a core backend access control failure. Temporary measures might involve stricter rate limiting on deletion endpoints until a complete fix is deployed, but this does not address the root cause.
## Detection
- Indicators of Compromise: High volume of successful `DELETE` requests originating from accounts that are clearly not the content owner for specific Post IDs.
- Detection methods and tools: API monitoring tools configured to review authorization layer checks on all mutating endpoints (`POST`, `PUT`, `DELETE`).
## References
- Vendor advisories: Not available in the provided context.
- Relevant links - defanged: No external links provided in the text summary.