Description

Plane is an open-source project management tool. Prior to 1.4.0, the V2 issue-attachment PATCH endpoint accepts issue_id in the URL but omits it from the database query. A project member can use an issue_id they control in the URL while targeting another user's attachment by its pk UUID. Because the server matches only pk, workspace, and project_id, it modifies the attachment regardless of the issue_id in the URL. When the attachment is pending and has not been confirmed as uploaded, the PATCH handler sets created_by = request.user and transfers attachment ownership to the attacker. This issue is fixed in 1.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-10-05T18:17:36.757Z",
  "pubdate": "2026-10-05T18:17:36.757Z",
  "executiveSummary": "Plane, an open-source project management tool, contains an Insecure Direct Object Reference (IDOR) vulnerability in its V2 issue-attachment PATCH endpoint.\nThe vulnerability allows an authenticated project member to manipulate the ownership of pending file attachments associated with other users or issues they do not control.\nBy bypassing intended access controls, an attacker can hijack the 'created_by' attribute of a file, effectively transferring ownership of the pending attachment to their own account.\nThis flaw exists due to an improper implementation of database queries where the supplied 'issue_id' parameter in the URL is disregarded in favor of the 'pk' (primary key) UUID for authorization checks.\nThe risk implication includes unauthorized data manipulation and potential account-based attribution spoofing for attachments within the workspace.\nThe issue affects versions of Plane prior to 1.4.0, necessitating an immediate upgrade for affected deployments.",
  "technicalDetails": "The vulnerability is situated within the V2 issue-attachment PATCH endpoint of the Plane application, specifically affecting the logic responsible for updating attachment metadata.\nThe root cause is a failure to properly validate the relationship between the 'issue_id' provided in the request URL and the target attachment identified by the 'pk' UUID.\nDuring the execution of the PATCH request, the application performs a database lookup based solely on the 'pk', 'workspace', and 'project_id' parameters.\nBecause the 'issue_id' is ignored in the backend query, the application fails to verify if the specified attachment actually belongs to the issue defined in the request path.\nThe exploitation flow proceeds as follows: 1) An attacker identifies a pending attachment UUID ('pk') belonging to another user within the same workspace or project. 2) The attacker constructs a PATCH request targeting the vulnerable endpoint, supplying their own legitimate 'issue_id' in the URL to satisfy initial routing constraints. 3) The server processes the request, locates the target attachment via the 'pk' parameter, and ignores the mismatched 'issue_id'. 4) Upon processing the payload, the application's PATCH handler updates the 'created_by' field of the attachment to the attacker's user ID.\nThis behavior specifically triggers when the attachment state is pending and unconfirmed, allowing for the successful subversion of ownership metadata.\nPost-exploitation impact involves the attacker assuming control over the attachment record, which could potentially lead to further unauthorized file access, data integrity issues, or the manipulation of workspace audit trails, as the attachment is now associated with the attacker's identity.\nThe vulnerability requires the attacker to be an authenticated project member with access to the target workspace, as the current authorization checks correctly validate project membership but fail to perform the granular authorization check required for the specific object reference.\nThe issue is explicitly scoped to versions prior to 1.4.0, where the backend query logic lacks the necessary restrictive filters to ensure the 'issue_id' context is maintained."
}