Description

Plane is an open-source project management tool. Prior to 1.4.0, Plane exposes the workspace-scoped GET /api/assets/v2/workspaces/{workspace_slug}/download/{asset_id}/ endpoint for project-bound FileAsset objects without enforcing access to the asset's owning project. An authenticated user who belongs to the same workspace, is not a member of the victim's secret project, and knows the target asset UUID can receive a 302 redirect to a signed download URL. The intended project-scoped route for the same asset correctly returns 403. Confirmed affected project-bound asset types are ISSUE_ATTACHMENT, COMMENT_DESCRIPTION, PAGE_DESCRIPTION, and PROJECT_COVER. This bypass exposes private file content protected by the secret project boundary. 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.307Z",
  "pubdate": "2026-10-05T17:17:11.307Z",
  "executiveSummary": "Plane, an open-source project management tool, contains an Improper Authorization vulnerability in versions prior to 1.4.0 within its asset management API.\nThe vulnerability resides in the workspace-scoped asset download endpoint, which fails to validate whether an authenticated user possesses the necessary permissions to access assets bound to specific, private projects.\nAn authenticated user sharing a workspace with a target project can successfully bypass intended access control boundaries to retrieve sensitive files.\nThis flaw allows unauthorized access to private content, including issue attachments, comment descriptions, page descriptions, and project covers.\nExploitation requires the attacker to possess a valid authentication session within the same workspace and knowledge of the target asset's UUID.\nThe impact includes unauthorized information disclosure, as restricted project data is rendered accessible to unauthorized internal users, compromising the confidentiality of sensitive documentation and file assets within the organization's workspace.",
  "technicalDetails": "The vulnerability is located in the GET /api/assets/v2/workspaces/{workspace_slug}/download/{asset_id}/ endpoint, which is designed to facilitate asset retrieval within a workspace context.\nThe root cause is a failure in the authorization logic of the API implementation: the system performs a workspace-level validation but neglects to verify if the requester has explicit authorization for the specific project associated with the requested FileAsset.\nWhile the application provides a distinct project-scoped route that correctly enforces access control—returning a 403 Forbidden status when access is denied—the workspace-scoped endpoint lacks this granular check.\nThe attack flow proceeds as follows: First, an authenticated attacker identifies the UUID of a target asset belonging to a private project within their shared workspace. Second, the attacker crafts a request to the vulnerable workspace-scoped download endpoint using the known {workspace_slug} and {asset_id}. Third, because the API backend only verifies membership within the workspace, it erroneously authorizes the request, returning a 302 HTTP redirect to a signed URL.\nFinally, the attacker follows the signed URL to retrieve the protected file content. This bypass mechanism affects multiple asset types, specifically ISSUE_ATTACHMENT, COMMENT_DESCRIPTION, PAGE_DESCRIPTION, and PROJECT_COVER.\nThe vulnerability is restricted to authenticated users, but it effectively escalates the privileges of standard workspace members by granting them unauthorized access to data restricted to private projects. The exposure allows for the exfiltration of sensitive organizational data, violating the project-level boundary constraints defined by the system's security architecture.\nThe vulnerability is confirmed in versions prior to 1.4.0 and is successfully remediated in the 1.4.0 release through the implementation of proper project-bound access control checks on the affected endpoint."
}