CVE-2026-104975 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, Plane's dashboard asset endpoints in plane/app/views/asset/v2.py were remediated for two cross-tenant asset IDORs, CVE-2026-27705 and CVE-2026-46558. Those fixes added a membership check and project_id and workspace__slug scoping to the asset endpoints in that file. The Spaces app in plane/space/views/asset.py serves related public-board operations under /api/public/ but was not remediated. Its EntityAssetEndpoint and AssetRestoreEndpoint resolve a DeployBoard from a public anchor and then read or modify FileAsset rows scoped only to the board's workspace, without a membership check or project_id constraint. An attacker can therefore read, overwrite, or restore assets across projects and workspaces. This issue is fixed in 1.4.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified as CVE-2026-27705 and related to the broader context of CVE-2026-46558 represents a critical Insecure Direct Object Reference (IDOR) flaw within Plane, an open-source project management platform. This security defect stems from insufficient authorization checks in specific API endpoints that handle asset operations for public boards. While earlier versions attempted to remediate similar issues by implementing membership verification and strict scoping based on workspace slugs and project identifiers, a parallel code path remained unpatched. Specifically, the Spaces application located at plane/space/views/asset.py serves functionality under the /api/public/ route prefix, which is intended for public-facing board operations but inadvertently exposes sensitive internal logic to unauthorized actors.
The technical root cause lies in the EntityAssetEndpoint and AssetRestoreEndpoint classes within this module. These endpoints are designed to resolve a DeployBoard from a publicly accessible anchor point. Once resolved, they proceed to read or modify FileAsset database rows that are scoped only by the board's associated workspace identifier. Crucially, these operations lack any verification of whether the requesting user is a member of the target project or has explicit permission to access the specific asset in question. This architectural oversight allows an attacker who possesses knowledge of valid internal identifiers for assets across different projects and workspaces to bypass intended isolation boundaries. The absence of a membership check means that authentication alone, or even no authentication if public endpoints allow it, is insufficient to prevent unauthorized data manipulation.
The operational impact of this vulnerability is severe, enabling attackers to perform read, overwrite, and restore operations on files belonging to other tenants within the multi-tenant architecture of Plane. An adversary can exfiltrate sensitive documents stored in assets from projects they do not belong to, effectively violating confidentiality requirements. Furthermore, by overwriting or restoring these assets, an attacker can compromise data integrity and availability. This capability allows for potential denial-of-service conditions through asset deletion or corruption, as well as the insertion of malicious content into shared project spaces if those files are subsequently accessed by legitimate users. The ability to restore deleted assets further complicates incident response efforts, as attackers may retain persistent access to compromised resources even after initial remediation attempts.
This vulnerability aligns with CWE-639, which describes Authorization Bypass Through User-Controlled Key, a common pattern in web applications where direct references to internal objects are exposed without proper permission validation. From an offensive security perspective, this behavior is characteristic of the ATT&CK technique T1078, Valid Accounts, particularly when exploited by authenticated users who leverage their access to traverse lateral boundaries between tenants. It also reflects aspects of T1530, Data from Cloud Storage Object, if the assets contain sensitive information stored in cloud-backed storage systems linked to Plane instances. The failure to enforce strict multi-tenant isolation highlights a gap in the application's security design regarding public-facing APIs that interact with private data models.
To mitigate this vulnerability, organizations running versions of Plane prior to 1.4.0 must upgrade immediately to version 1.4.0 or later, where these specific endpoints have been patched. The fix involves implementing rigorous membership verification and enforcing strict scoping constraints based on both project_id and workspace__slug for all asset-related operations in the Spaces application. For environments that cannot yet upgrade, temporary mitigations should include restricting access to the /api/public/ route if public board features are not required, or applying network-level controls such as Web Application Firewall rules to block requests containing suspicious patterns indicative of IDOR exploitation attempts. Continuous monitoring for anomalous asset access patterns across different workspaces can also aid in detecting potential exploitation activities before significant damage occurs.