CVE-2026-104963 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, GET /api/workspaces/{slug}/cycles/ through WorkspaceCyclesEndpoint and GET /api/workspaces/{slug}/modules/ through WorkspaceModulesEndpoint return records from every project in a workspace without checking whether the requester belongs to each project. Any authenticated workspace member, including a Guest with access to only one project, can enumerate names, descriptions, sprint dates, issue counts, progress snapshots, external integration IDs, linked URLs, and member lists for cycles and modules in private projects. The sibling WorkspaceLabelsEndpoint and WorkspaceStatesEndpoint apply the correct project__project_projectmember__member=request.user filter, making the cycle and module endpoints inconsistent outliers. This issue is fixed in 1.4.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in Plane versions prior to 1.4.0 represents a critical failure in access control logic within the application's API layer, specifically affecting how workspace-level resources are filtered against project-level permissions. Plane serves as an open-source project management platform where users interact with workspaces containing multiple projects of varying privacy levels. The core technical flaw resides in two specific endpoints: GET /api/workspaces/{slug}/cycles/ and GET /api/workspaces/{slug}/modules/. These endpoints, implemented via WorkspaceCyclesEndpoint and WorkspaceModulesEndpoint respectively, are designed to retrieve lists of cycles (sprints) and modules associated with a given workspace. However, the implementation fails to enforce granular access controls that restrict data retrieval based on the requesting user's membership status within individual projects contained in that workspace.
In a properly secured environment, an authenticated user should only be able to view resources belonging to projects where they have explicit permission. In this flawed implementation, any authenticated member of a workspace can query these endpoints and receive records for every cycle and module across all projects within that workspace, regardless of whether the requester is a member of those specific private projects. This behavior creates an inconsistency when compared to sibling endpoints such as WorkspaceLabelsEndpoint and WorkspaceStatesEndpoint, which correctly apply filters like request.user in their database queries to ensure users only see data from projects they are part of. The lack of this filtering mechanism allows for unauthorized information disclosure, enabling attackers or malicious insiders to bypass project-level privacy settings entirely through simple API calls.
The operational impact of this vulnerability is significant due to the breadth of sensitive data exposed during enumeration attacks. An attacker with guest access to a single low-privilege project can enumerate comprehensive details about cycles and modules in private projects where they have no intended access. This includes retrieving names, descriptions, sprint dates, issue counts, progress snapshots, external integration IDs, linked URLs, and member lists associated with those resources. The exposure of external integration IDs and linked URLs is particularly dangerous as it may reveal connections to third-party services or internal infrastructure endpoints that could be targeted in subsequent attacks. Furthermore, the disclosure of member lists for cycles and modules can aid attackers in mapping out organizational structures and identifying high-value targets within private projects, facilitating social engineering or further privilege escalation attempts.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves insufficient restrictions on access to data resources. It also maps closely to ATT&CK technique T1078 Valid Accounts and potentially T1539 Steal Web Session Cookie if the authentication token is compromised, though primarily it represents a logic flaw in authorization rather than authentication failure. The inconsistency with other endpoints highlights a systemic issue in how permissions are propagated from project-level contexts up to workspace-level aggregations, suggesting that similar vulnerabilities may exist in other aggregated views within the application architecture.
To mitigate this vulnerability, organizations running Plane versions prior to 1.4.0 should upgrade immediately to version 1.4.0 or later, where the issue has been resolved by implementing proper filtering logic consistent with sibling endpoints. For environments unable to patch immediately due to dependency constraints, network-level controls such as Web Application Firewalls can be configured to restrict access to these specific API paths based on user roles if role-based segmentation is available in the deployment architecture. Additionally, security teams should audit other workspace-level aggregation endpoints for similar permission bypasses, ensuring that all data retrieval operations enforce strict project-level membership checks before returning results. Regular penetration testing focusing on horizontal privilege escalation and information disclosure through API enumeration is recommended to identify any residual or related access control flaws in the application's logic layer.