CVE-2026-104962 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, GET /api/v1/workspaces/{slug}/projects/{project_id}/members/ returns the complete project-member roster, including each member's email address, first and last name, display name, avatar, and role. ProjectMemberPermission gates the endpoint, but its SAFE_METHODS branch checks only whether the caller is an active ProjectMember of any project in the workspace and does not bind the check to view.project_id. The view then filters solely by the project_id supplied in the URL. Consequently, any authenticated user who belongs to one project in a workspace, including a Guest, can read the roster of another private project in the same workspace. This issue is fixed in 1.4.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in Plane versions prior to 1.4.0 represents a critical authorization flaw within the application's API layer, specifically affecting the endpoint responsible for retrieving project member rosters. As an open-source project management tool, Plane relies on strict access control mechanisms to ensure that sensitive organizational data remains confined to authorized personnel. The specific weakness lies in the GET /api/v1/workspaces/{slug}/projects/{project_id}/members/ API route, which is designed to return comprehensive details about individuals associated with a given project, including email addresses, names, display names, avatars, and roles. This information constitutes personally identifiable information and organizational structure data that should be strictly protected based on the user's relationship to the specific resource being accessed.
The root cause of this vulnerability stems from an incorrect implementation of the ProjectMemberPermission gate within the application's backend logic. The permission system utilizes a SAFE_METHODS branch intended to verify whether the authenticated caller is an active member of any project within the target workspace. However, this check fails to bind the authorization decision to the specific project_id provided in the URL parameters. Instead of validating that the user has explicit permissions for the requested project, the logic merely confirms membership in some arbitrary project within the same workspace. This logical error creates a situation where the access control mechanism is effectively bypassed because the scope of the permission check does not align with the scope of the resource being accessed.
Consequently, any authenticated user who holds member status in at least one project within a workspace can exploit this flaw to enumerate the complete roster of other private projects hosted on that same workspace. This includes users with Guest roles, which typically have restricted permissions and should not be able to view detailed information about non-public collaborations. The operational impact is significant, as it allows for unauthorized data disclosure and potential social engineering attacks by exposing internal team structures and contact details without proper justification or authorization. Such exposure violates the principle of least privilege and compromises the confidentiality of private project communications and personnel assignments.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically reflecting a failure to enforce restrictions on data access for unauthorized actors. In terms of offensive security frameworks, this behavior corresponds to ATT&CK technique T1078, Valid Accounts, where an attacker leverages legitimate credentials to access resources they are not authorized to view, and potentially T1539, Steal Web Session Cookie, if the exposed email addresses facilitate targeted phishing campaigns. The flaw highlights a common pitfall in web application development where permission checks are applied too broadly rather than being tightly coupled with specific resource identifiers.
To mitigate this issue, developers must ensure that authorization logic explicitly validates the user's permissions against the specific resource identifier present in the request context. In Plane version 1.4.0 and later, this has been corrected by binding the ProjectMemberPermission check to the view.project_id parameter, ensuring that users can only access member lists for projects they are directly authorized to view. Organizations running older versions should upgrade immediately to patch this exposure. Additionally, implementing comprehensive logging of authorization failures and conducting regular code audits focused on object-level permission checks can help prevent similar vulnerabilities in future development cycles.