Description

Plane is an open-source project management tool. Prior to 1.4.0, DuplicateAssetEndpoint fetches a source FileAsset without limiting it to the caller's workspace, allowing cross-workspace asset duplication. WorkspaceFileAssetEndpoint and the legacy FileAssetEndpoint omit workspace authorization, allowing authenticated users to read, create, modify, or delete assets in workspaces where they are not members. Separately, WorkspaceViewViewSet.retrieve lacks the authorization decorator used by its sibling actions, exposing an unauthorized workspace-view read surface. This issue is fixed in 1.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-10-05T18:17:32.113Z",
  "pubdate": "2026-10-05T18:17:32.113Z",
  "executiveSummary": "Plane, an open-source project management tool, contains multiple critical broken access control vulnerabilities affecting versions prior to 1.4.0. These flaws allow authenticated users to perform unauthorized actions across different workspaces, circumventing organizational isolation boundaries.\nThe vulnerabilities manifest as improper authorization checks in specific API endpoints, specifically those handling asset management and view retrieval. Attackers can leverage these flaws to read, create, modify, or delete assets within workspaces where they lack membership, as well as access unauthorized project views.\nThe risk implication is significant, as these vulnerabilities enable cross-workspace data exfiltration, unauthorized content modification, and potential unauthorized access to sensitive project metadata. Exploitation requires an authenticated user account within the system, but does not necessitate administrative privileges within the target workspace. The lack of proper scope validation in the backend logic effectively exposes all workspace assets and views to any authenticated user in the environment, undermining the platform's multi-tenant isolation model.",
  "technicalDetails": "The vulnerabilities stem from a failure to enforce workspace-level authorization scoping across multiple API endpoints. In the DuplicateAssetEndpoint, the logic responsible for fetching a source FileAsset fails to validate that the requested asset belongs to the caller's authorized workspace. This allows an authenticated attacker to duplicate assets from any workspace into their own, effectively bypassing horizontal access controls.\nSimilarly, the WorkspaceFileAssetEndpoint and the legacy FileAssetEndpoint suffer from a lack of workspace authorization enforcement. These endpoints handle CRUD operations for FileAssets. Because the backend fails to verify the relationship between the authenticated user and the specific workspace associated with the target asset, an attacker can manipulate assets—including reading sensitive files, creating unauthorized entries, or deleting existing assets—in any workspace across the entire deployment.\nFurthermore, the WorkspaceViewViewSet.retrieve action is missing a mandatory authorization decorator present in its sibling view actions. This oversight exposes an unauthorized read surface, allowing attackers to retrieve project view details for workspaces they are not authorized to access. This leads to the exposure of sensitive metadata related to project structures and workflows.\nThe attack flow for these vulnerabilities generally follows a pattern of requesting a specific object ID (asset or view) via the API without providing proper scoping context or by providing an ID from a foreign workspace. Because the backend functions (such as DuplicateAssetEndpoint or the retrieve method) operate on the provided ID without verifying that the requester is a member of the corresponding workspace, the server processes the request as if it were legitimate. This allows for unauthorized operations as long as the attacker has a valid authentication session on the Plane instance. The root cause is the reliance on implicit trust rather than explicit, per-request authorization checks that validate the workspace ownership of the requested resources."
}