Summary
Plane's V2 issue-attachment PATCH endpoint may authorize an attachment using its UUID without verifying that the attachment belongs to the issue identified in the URL. A project member who can access the endpoint may modify another user's pending attachment and, in certain states, transfer its ownership to themselves.
Plane's V2 issue-attachment PATCH endpoint may authorize an attachment using its UUID without verifying that the attachment belongs to the issue identified in the URL. A project member who can access the endpoint may modify another user's pending attachment and, in certain states, transfer its ownership to themselves.
Affected context
The issue occurs in Plane deployments using the affected V2 issue-attachment PATCH handler. Risk is present when a project member can submit attachment updates, the request identifies an attachment by its primary-key UUID, and the server does not confirm that the attachment is associated with the issue_id supplied in the URL. Pending, unconfirmed attachments are particularly sensitive because the handler may replace their creator with the requesting user.
The issue occurs in Plane deployments using the affected V2 issue-attachment PATCH handler. Risk is present when a project member can submit attachment updates, the request identifies an attachment by its primary-key UUID, and the server does not confirm that the attachment is associated with the issue_id supplied in the URL. Pending, unconfirmed attachments are particularly sensitive because the handler may replace their creator with the requesting user.
Exploit preconditions
- Attack surface: V2 issue-attachment PATCH API
- Required access: Project-member access sufficient to submit attachment updates
- Targeting requirement: Knowledge of, or access to, another attachment's primary-key UUID
- Trigger point: An attachment update request containing a controlled issue_id and target attachment identifier
- Why exploitation is possible: Authorization and database selection use the attachment UUID, workspace, and project identifiers without binding the record to the issue_id in the URL
- Attack surface: V2 issue-attachment PATCH API
- Required access: Project-member access sufficient to submit attachment updates
- Targeting requirement: Knowledge of, or access to, another attachment's primary-key UUID
- Trigger point: An attachment update request containing a controlled issue_id and target attachment identifier
- Why exploitation is possible: Authorization and database selection use the attachment UUID, workspace, and project identifiers without binding the record to the issue_id in the URL
Why this happens
The underlying bug is an object-level authorization failure mapped to CWE-639. The endpoint accepts an issue identifier as part of the resource path but omits that identifier from the database lookup and ownership authorization relationship. As a result, a valid attachment UUID can select an object outside the requested issue context, and state-dependent update logic can apply changes using the attacker's identity.
The underlying bug is an object-level authorization failure mapped to CWE-639. The endpoint accepts an issue identifier as part of the resource path but omits that identifier from the database lookup and ownership authorization relationship. As a result, a valid attachment UUID can select an object outside the requested issue context, and state-dependent update logic can apply changes using the attacker's identity.
Potential impact
- An attacker may modify another user's attachment metadata or state.
- An attacker could transfer ownership of eligible pending attachments.
- Users may lose control or attribution of uploaded project content.
- Project records and collaboration workflows may be manipulated.
- The flaw can contribute to unauthorized disclosure or destructive changes if attachment updates expose additional functionality.
- An attacker may modify another user's attachment metadata or state.
- An attacker could transfer ownership of eligible pending attachments.
- Users may lose control or attribution of uploaded project content.
- Project records and collaboration workflows may be manipulated.
- The flaw can contribute to unauthorized disclosure or destructive changes if attachment updates expose additional functionality.
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization at every
lookup and update boundary.
Common defensive patterns include:
- Bind all path and request identifiers, including issue_id, to the database query and authorization check.
- Verify workspace, project, issue, attachment, and user relationships before applying changes.
- Use centralized authorization policies that evaluate the target object rather than relying on client-supplied context.
- Restrict ownership changes to explicit, authorized workflows and preserve server-side attribution.
- Apply least-privilege permissions and minimize which project members can update attachment state.
- Return consistent not-found or authorization responses without revealing whether unrelated object identifiers exist.
Mitigation generally focuses on enforcing object-level authorization at every
lookup and update boundary.
Common defensive patterns include:
- Bind all path and request identifiers, including issue_id, to the database query and authorization check.
- Verify workspace, project, issue, attachment, and user relationships before applying changes.
- Use centralized authorization policies that evaluate the target object rather than relying on client-supplied context.
- Restrict ownership changes to explicit, authorized workflows and preserve server-side attribution.
- Apply least-privilege permissions and minimize which project members can update attachment state.
- Return consistent not-found or authorization responses without revealing whether unrelated object identifiers exist.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and review rules that flag resource lookups using only a UUID while ignoring parent-resource identifiers.
- Code review checks for authorization performed after object selection or only against workspace and project scope.
- API tests that pair valid child-object identifiers with mismatched parent identifiers.
- Regression tests covering ownership, pending-state transitions, and cross-user attachment updates.
- Policy enforcement requiring every object mutation endpoint to validate the complete resource hierarchy.
- Audit-log monitoring for attachment changes where the actor, issue, and recorded owner do not align.
Organizations can look for this class of issue through:
- Static analysis and review rules that flag resource lookups using only a UUID while ignoring parent-resource identifiers.
- Code review checks for authorization performed after object selection or only against workspace and project scope.
- API tests that pair valid child-object identifiers with mismatched parent identifiers.
- Regression tests covering ownership, pending-state transitions, and cross-user attachment updates.
- Policy enforcement requiring every object mutation endpoint to validate the complete resource hierarchy.
- Audit-log monitoring for attachment changes where the actor, issue, and recorded owner do not align.
