Plane CVE-2026-105633

Requires an authenticated account that is a member of the target Plane project (PR:L), so this is not remote-unauthenticated. The attacker must target an attachment that is still in the PENDING state (not yet confirmed as uploaded) - confirmed attachments are unaffected - and must know the victim attachment's pk UUID, since the server matches on pk, workspace, and project_id. These factors (authenticated project membership, the narrow pending-upload window, and the need for an unguessable UUID) materially limit realistic exploitation despite the network attack vector. No special non-default configuration is needed; the flaw is present in the default V2 issue-attachment PATCH endpoint in versions prior to 1.4.0.

This is a genuine but moderate-priority authorization flaw (CWE-639, insecure direct object reference). The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L, base 7.1) is consistent with the description: a network-reachable API endpoint, low complexity, and an authenticated low-privilege project member required (PR:L). There is no confidentiality impact (C:N) because the bug reassigns attachment ownership rather than disclosing content; integrity is rated high (I:H) and availability low (A:L) reflecting unauthorized modification and loss of ownership for the legitimate user. No EPSS score was supplied and the CVE is NOT on CISA KEV, so there is no evidence of active exploitation - status is 'no public exploit identified at time of analysis'. A key mitigating nuance the raw CVSS does not capture: exploitation is limited to attachments still in the PENDING (not-yet-confirmed-uploaded) state and requires the attacker to know the target attachment's pk UUID, which is not easily enumerable. The vendor fix commit and PR diff are public, which lowers the bar for a patch-diffing attacker even though no weaponized POC is published. Overall this is a legitimate authorization bug worth patching but not an emergency; the 7.1 score slightly overstates practical risk given the pending-only window and UUID prerequisite.

An authenticated low-privilege member of a Plane project learns or obtains the pk UUID of another user's attachment that is still in the pending (unconfirmed-upload) state. The attacker sends a V2 issue-attachment PATCH request supplying an issue_id they control in the URL but the victim's attachment pk, and because the server matches only pk, workspace, and project_id, it reassigns created_by to the attacker, transferring ownership. No public POC is identified, though the fix commit and PR diff are publicly available.