Plane EUVD-2026-92478

Attacker must already hold an authenticated Project Member account at role 15 within the target project/workspace, and a Project Guest (role 5) must exist in the same project to be promoted. Exploitation is a single PATCH request to /api/workspaces/{workspace_slug}/projects/{project_id}/members/{member_pk}/ setting the new role equal to the attacker's Member role, which bypasses the check that only blocks strictly-higher roles. Limiting factors: requires valid in-project membership (not remote-unauthenticated), the escalation is capped at the attacker's own role level (cannot reach Project Admin role 20), and it affects only Plane deployments prior to version 1.4.0.

This is a moderate-severity, authenticated privilege-escalation flaw (CWE-269) rather than a high-urgency issue. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) correctly reflects that an attacker must already be a legitimate authenticated Project Member (PR:L) - this is NOT unauthenticated. The attack is network-reachable with low complexity and no user interaction, but the ceiling is capped: the flawed check blocks assigning a role HIGHER than the requester's own, so a role-15 Member can only promote a role-5 Guest UP TO the equal Member role - it does not permit escalation to Project Admin (role 20) or workspace takeover. No EPSS score, KEV listing, or SSVC decision data was supplied; there is no CISA KEV entry and no public exploit referenced, only the vendor patch/PR. Signals are internally consistent (no CVSS-vs-description conflict), but the real-world risk is bounded by the insider-access prerequisite and the limited impact of a one-step Guest→Member promotion. Priority: patch in normal cycles; this is a governance/authorization-bypass bug, not a mass-exploitation threat.

A disgruntled or compromised regular Project Member (role 15) in a Plane workspace sends a crafted PATCH request to the project-member update endpoint, assigning the equal Member role to an existing Project Guest (role 5). Because the validation only rejects roles strictly higher than the requester's, the equal-role assignment slips through, silently promoting the Guest to Member and bypassing the requirement for Project Admin approval. No public exploit code is referenced; only the fixing PR diff is available.