CVE-2026-105637 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, ProjectBulkAssetEndpoint.post in apps/api/plane/app/views/asset/v2.py retrieves assets using id__in=asset_ids and workspace__slug=slug but does not constrain the query with project_id from the URL. A workspace Guest can provide asset UUIDs from another project in the same workspace and reassign their issue_id, comment_id, page_id, draft_issue_id, or project_id to an entity the attacker controls. Plane then treats the attacker's project as the new owner and provides a presigned download URL for the hijacked file. 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 Insecure Direct Object Reference (IDOR) flaw within the ProjectBulkAssetEndpoint, specifically located in the post method of apps/api/plane/app/views/asset/v2.py. This endpoint is designed to manage bulk operations on assets associated with projects, yet it fails to enforce proper authorization checks regarding project ownership during asset reassignment or retrieval processes. The core technical deficiency lies in the database query logic, which filters results based solely on workspace slug and a provided list of asset identifiers using an id__in clause. Crucially, the implementation omits any constraint linking these assets to the specific project_id derived from the URL parameters or session context. This architectural oversight allows for significant scope ambiguity, where the system treats all assets within a given workspace as potentially accessible regardless of their actual project affiliation.
From an operational perspective, this flaw enables authenticated users with lower privilege levels, such as Workspace Guests, to perform unauthorized actions that should be restricted to higher-privileged roles like Project Owners or Admins. An attacker can exploit this by supplying asset UUIDs belonging to assets owned by other projects within the same workspace. By manipulating parameters related to issue_id, comment_id, page_id, draft_issue_id, or project_id, the attacker can reassign these external assets to entities they control. Once the system processes this request without validating that the target assets belong to the authenticated user's designated project context, it updates the ownership records accordingly. This effectively allows for horizontal privilege escalation within the workspace structure, as a guest gains administrative-like capabilities over resources outside their assigned scope.
The impact of this vulnerability extends beyond simple data manipulation; it facilitates unauthorized access to sensitive files and intellectual property stored within the platform. After successfully hijacking an asset by reassigning its ownership or association, Plane generates a presigned download URL for the compromised file. This mechanism provides the attacker with direct, unauthenticated-style access to download the content of assets they do not own. Consequently, this leads to a severe breach of confidentiality and data integrity. Sensitive documents, code repositories, design files, or other proprietary information stored in projects controlled by others can be exfiltrated without detection, undermining the fundamental security model of multi-tenant project management environments where isolation between different teams or departments is expected.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically highlighting failures to enforce proper restrictions on authorized individuals accessing specific data objects. Furthermore, it maps to MITRE ATT&CK technique T1078, Valid Accounts, as the attacker leverages legitimate but low-privileged credentials to perform unauthorized actions that escalate their effective privileges within the application logic. The lack of vertical and horizontal access control checks is a common pitfall in RESTful API implementations where developers assume URL parameters implicitly define scope without explicit validation against backend ownership records.
To mitigate this vulnerability, organizations running Plane versions prior to 1.4.0 must upgrade immediately to version 1.4.0 or later, which contains the necessary code corrections to enforce strict project-level authorization checks on asset operations. For environments where immediate upgrading is not feasible due to operational constraints, temporary mitigations should focus on network-level access controls and API gateway rules that restrict direct invocation of the vulnerable endpoint by guest-tier users until a patch can be applied. Additionally, implementing rigorous input validation at the application layer to ensure that any provided asset identifiers are verified against the authenticated user's project ownership records before processing reassignment requests is essential for preventing similar logic flaws in custom integrations or future development cycles. Regular security audits focusing on IDOR patterns and strict adherence to principle of least privilege during API design can further reduce the risk profile associated with such access control failures.