Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-10-05T17:17:11.770Z",
  "pubdate": "2026-10-05T17:17:11.770Z",
  "executiveSummary": "Plane, an open-source project management tool, is vulnerable to an Insecure Direct Object Reference (IDOR) flaw due to missing authorization checks in its API endpoints. This vulnerability allows authenticated workspace members, including low-privileged guests, to bypass project-level access controls and retrieve sensitive information from private projects within the same workspace.\nThe vulnerability exists in the WorkspaceCyclesEndpoint and WorkspaceModulesEndpoint, which fail to validate whether the requester maintains membership in the specific projects being queried. Consequently, an attacker can enumerate private project data—including sprint schedules, issue counts, and member lists—by querying resources across the entire workspace. This flaw compromises the confidentiality of private project metadata and operational workflows. Given the lack of granular permission enforcement, any user with authenticated access to a workspace can illicitly harvest project intelligence, posing a significant risk to organizational data isolation policies. The issue is resolved in version 1.4.0 by enforcing project membership filters consistent with other workspace-level endpoints.",
  "technicalDetails": "The vulnerability is rooted in an authorization bypass within the backend API logic of Plane prior to version 1.4.0. Specifically, the WorkspaceCyclesEndpoint and WorkspaceModulesEndpoint fail to implement proper object-level security filters. While other sibling endpoints—such as WorkspaceLabelsEndpoint and WorkspaceStatesEndpoint—correctly utilize the project__project_projectmember__member=request.user filter to restrict data retrieval to projects where the authenticated user is a member, these two specific endpoints lack this restrictive lookup.\nThe attack flow follows a predictable pattern of API exploitation. An authenticated attacker, acting with valid credentials but restricted privileges (e.g., a guest user associated with a single project), directs HTTP GET requests to the vulnerable endpoints: /api/workspaces/{slug}/cycles/ or /api/workspaces/{slug}/modules/. Because the application backend fails to validate the user’s project membership against the requested objects during the database query construction, the system returns comprehensive records for all cycles and modules associated with the workspace, irrespective of their privacy status or project affiliation.\nBy systematically iterating through these endpoints, an attacker can extract sensitive metadata including cycle names, detailed descriptions, start and end dates, current issue counts, progress snapshots, internal external integration identifiers, and linked URLs. Furthermore, the exposure of member lists provides an opportunity for internal reconnaissance, mapping project contributors across the entire workspace. The exploitation does not require advanced technical skill or elevated administrative privileges; it is entirely achievable by an authenticated user performing unauthorized enumeration via standard HTTP requests.\nThe inconsistency in implementing access control logic across similar workspace endpoints highlights a failure in the application’s security design pattern. While the database models support complex relational filtering, the omission of these filters in the affected endpoints results in an IDOR vulnerability where the 'object' (the cycle or module) is accessed without 'reference' to the user's authorization status for that specific container. The impact is significant, as it leads to widespread information disclosure of private organizational structures and ongoing project activities, contradicting the platform's multi-tenant project isolation mechanisms. This vulnerability is strictly a backend authorization flaw; network exposure is inherent to the web-accessible API, and the exploitability is high for any user authenticated to the workspace."
}