Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-05T17:17:11.610Z",
  "pubdate": "2026-10-05T17:17:11.610Z",
  "executiveSummary": "A broken access control vulnerability exists in Plane prior to version 1.4.0 within the project member retrieval API endpoint. This flaw allows authenticated users to access unauthorized data regarding other users within a workspace.\nThe vulnerability is classified as an insecure direct object reference (IDOR) or improper authorization issue. An attacker, possessing only the status of a project member within a workspace, can enumerate the full roster of any private project within that same workspace.\nImpact includes the unauthorized disclosure of sensitive PII, including email addresses, full names, display names, and role assignments of members associated with projects the attacker is not authorized to view. This represents a significant privacy risk and potential reconnaissance vector for further targeted attacks.\nExploitation requires the attacker to be an authenticated user with valid workspace membership. No administrative privileges are required to perform the enumeration, as the authorization logic fails to validate the user's specific membership status against the requested project ID, relying instead on a broad, insufficiently scoped workspace-level permission check.",
  "technicalDetails": "The vulnerability resides within the GET /api/v1/workspaces/{slug}/projects/{project_id}/members/ endpoint. The root cause is a flaw in the ProjectMemberPermission class, which is responsible for mediating access to project-related resources.\nWhen processing a request, the ProjectMemberPermission logic utilizes a SAFE_METHODS branch that validates whether the requesting user is an active member of any project within the target workspace. However, this implementation is architecturally decoupled from the specific context of the requested project_id. Because the authorization check ignores the scoping relationship between the user and the specific project requested in the URL path, the system fails to enforce granular access controls.\nThe attack flow proceeds as follows: First, an authenticated attacker identifies a valid workspace slug and a target project_id for a private project they are not authorized to access. Second, the attacker issues a GET request to the vulnerable endpoint: /api/v1/workspaces/{slug}/projects/{project_id}/members/. Third, the backend system invokes the faulty ProjectMemberPermission class. The class confirms that the requester holds membership in at least one project within the target workspace, satisfying the overly permissive authorization criteria. Fourth, the view logic retrieves the full member roster associated with the supplied project_id from the database. Finally, the server serializes the comprehensive roster—containing email addresses, first and last names, display names, avatar URLs, and role assignments—and returns it in the HTTP response body.\nThis vulnerability is present in all versions prior to 1.4.0. The lack of resource-level binding in the authorization logic permits horizontal privilege escalation, where a Guest user or a member of a different project can harvest sensitive PII from restricted projects. There is no requirement for network-level access beyond standard API reachability; the vulnerability is strictly confined to the application logic layer where authorization checks occur.\nPost-exploitation impact involves the exposure of project-specific membership data, which could be utilized for social engineering, spear-phishing, or mapping internal organizational structures. The integrity of private project rosters is compromised as long as the requesting identity remains a valid member of any project within the same logical workspace container."
}