CVE-2026-102986 in Plane
Summary
by MITRE • 10/14/2026
Plane is an open-source project management tool. In 1.3.1 and earlier, EntityAssetEndpoint at the public project asset endpoint /api/public/assets/v2/anchor/{anchor}/ requires authentication for write operations but does not verify workspace or project membership. An authenticated user who knows a published project's public DeployBoard.anchor can create FileAsset records in that project and soft-delete existing assets by identifier, allowing cross-workspace file injection, storage abuse, and data loss. The issue is fixed in version 1.4.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in Plane versions prior to 1.4.0 represents a critical authorization flaw within the EntityAssetEndpoint located at /api/public/assets/v2/anchor/{anchor}/. This endpoint serves as an interface for managing file assets associated with public projects, specifically those utilizing the DeployBoard feature which generates unique anchor identifiers. While the API correctly enforces authentication requirements to prevent anonymous access, it fails to implement proper authorization checks regarding workspace or project membership. The core technical deficiency lies in the server-side logic that processes write operations such as creating new FileAsset records and soft-deleting existing assets based on their identifier. Instead of validating whether the authenticated user possesses legitimate ownership or collaborative rights within the specific workspace containing the target asset, the system relies solely on the presence of a valid authentication token and knowledge of the public anchor string. This architectural oversight allows any authenticated user to interact with resources belonging to other workspaces provided they can discover the relevant anchor identifier through publicly accessible project pages.
The operational impact of this vulnerability is severe due to its potential for cross-workspace data manipulation. An attacker who has obtained valid credentials, which may be acquired through phishing or credential stuffing attacks given that authentication alone is insufficient protection, can exploit this flaw by targeting any public project's DeployBoard anchor. By sending crafted HTTP requests with write methods such as POST or DELETE, the attacker can inject arbitrary files into projects they do not own, leading to cross-workspace file injection. This capability enables storage abuse where attackers consume organizational cloud storage quotas, potentially causing denial of service for legitimate users by exhausting available disk space. Furthermore, the ability to soft-delete existing assets allows an adversary to remove critical documentation or configuration files from other teams' workspaces without triggering immediate alerts related to unauthorized access attempts, as the request appears validly authenticated and targets a public endpoint. This results in significant data loss and disruption of business continuity for affected organizations.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, specifically reflecting issues where an actor is able to perform actions beyond their assigned permissions due to flawed access control logic. It also maps closely to CWE-862 Missing Authorization, as the application fails to enforce that users are authorized for specific resources before allowing modifications. In terms of offensive security frameworks, this behavior corresponds to MITRE ATT&CK technique T1078 Valid Accounts, where attackers leverage legitimate credentials to move laterally or escalate privileges within a system by exploiting misconfigured access controls rather than breaking authentication mechanisms directly. The exploitation path involves using valid user tokens to interact with public-facing APIs that lack granular resource-level permissions, highlighting the danger of exposing internal management endpoints through public interfaces without rigorous ownership verification.
To mitigate this vulnerability and prevent similar issues in future development cycles, it is imperative to implement strict object-level authorization checks on all write operations within the EntityAssetEndpoint. The application must verify that the authenticated user holds a valid membership role such as admin or member within the specific workspace associated with the target project before allowing file creation or deletion requests. Developers should adopt a principle of least privilege by ensuring that public endpoints only expose read-only data unless explicitly required for collaborative features, and even then, they must validate ownership relationships in the database layer rather than relying on client-side assumptions or simple anchor lookups. Upgrading to version 1.4.0 resolves this issue as it includes patches that enforce these necessary membership validations. Additionally, organizations should implement comprehensive logging and monitoring for asset modification events across all workspaces to detect any anomalous deletion patterns or sudden spikes in storage usage that may indicate ongoing exploitation attempts while migration efforts are underway.