Description

Plane is an open-source project management tool. Prior to 1.3.0, the ProjectMemberViewSet.partial_update method allows any project member, including a user with the lowest GUEST role, to modify another project member's role. The authorization check prevents assigning a role higher than the requester's role but does not prevent assigning a lower or equal role, allowing a Guest to demote Administrators and Members and deny them project control. This vulnerability is fixed in 1.3.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-10-05T19:17:17.330Z",
  "pubdate": "2026-10-05T19:17:17.330Z",
  "executiveSummary": "The vulnerability identified in Plane, occurring in versions prior to 1.3.0, constitutes an Improper Access Control flaw within the ProjectMemberViewSet.partial_update method. This security deficiency permits unauthorized project members, specifically those holding the lowest 'GUEST' role, to modify the permission levels of other project members.\nThe core issue stems from insufficient authorization logic that fails to validate the requester's authority to modify roles of existing members. While the system imposes a boundary preventing the escalation of roles above the requester's current level, it erroneously permits the demotion of high-privilege users, including project administrators and members.\nThe impact is critical for project integrity, as an authenticated attacker with guest access can systematically demote privileged users, effectively stripping them of project management capabilities and disrupting operational control. This flaw poses a significant risk to organizational project workflows and access management. Exploitation requires authenticated access to the project environment, with no further complex prerequisites, making it a highly accessible vector for malicious actors seeking to sabotage internal project administration.",
  "technicalDetails": "The vulnerability is located within the ProjectMemberViewSet.partial_update function of the Plane application. This endpoint is responsible for processing partial updates to project membership records, including the assignment and modification of user roles within a given project context.\nThe root cause of this flaw is a deficient authorization check implementation. When a request is made to modify a project member's role, the application performs a validation step that only compares the rank of the requested role against the requester's own role. Specifically, the logic prevents a user from assigning a role higher than their own (e.g., a GUEST cannot promote themselves to ADMIN). However, the implementation fails to enforce a principle of least privilege regarding the modification of roles for other users. It does not verify if the requester has the requisite administrative permissions to alter the membership status of others, regardless of whether the requested role is 'lower' or 'equal' to their current status.\nThe attack flow proceeds as follows: 1. An attacker authenticates to the platform and joins a project as a GUEST. 2. The attacker identifies the endpoint associated with ProjectMemberViewSet.partial_update and constructs a malicious PATCH or PUT request targeting a specific project member ID. 3. The attacker sets the payload to modify the target user's role to a lower privilege level, such as changing an ADMIN to a GUEST. 4. The server-side authorization logic checks if the new target role is higher than the attacker's role. Since it is not, the check passes. 5. The application updates the database, successfully demoting the target user.\nThe vulnerability is present in versions prior to 1.3.0. The lack of granular permission verification means that any authenticated user within a project can exercise administrative control over other members' roles, leading to a state of denial of service regarding administrative functionality for legitimate project leaders. This effectively allows an attacker to destabilize project management and lock out authorized personnel from performing necessary maintenance or project oversight functions.\nGiven that the application processes these requests via standard API calls, the exposure is limited to authenticated project participants. However, in environments with open or easily accessible project memberships, this provides a direct path for internal sabotage or unauthorized privilege manipulation."
}