CVE-2026-104966 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, two endpoint families fail to verify that nested resource identifiers belong to the workspace and project named in the URL. An authenticated user can read or modify estimates from another workspace through PATCH /api/workspaces/{slug}/projects/{project_id}/estimates/{estimate_id}/, and can inject comments into an issue from another workspace through POST /api/workspaces/{slug}/projects/{project_id}/issues/{issue_id}/comments/. ProjectEntityPermission verifies membership in the workspace and project from the URL, but estimate_id and issue_id are fetched by primary key without confirming the same scope. The list, retrieve, and destroy handlers correctly scope their queries, demonstrating the inconsistency. This issue is fixed in 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/05/2026
The vulnerability identified involves a critical Insecure Direct Object Reference (IDOR) flaw within Plane, an open-source project management application, specifically affecting versions prior to 1.4.0. The core technical deficiency lies in the inconsistent implementation of authorization checks across different API endpoint families. While certain handlers such as those for listing, retrieving, and destroying resources correctly scope their database queries by verifying that the resource belongs to the workspace and project specified in the URL parameters, other endpoints fail to perform this same verification. Specifically, the PATCH endpoint for updating estimates at /api/workspaces/{slug}/projects/{project_id}/estimates/{estimate_id}/ and the POST endpoint for injecting comments into issues at /api/workspaces/{slug}/projects/{project_id}/issues/{issue_id}/comments/ rely on primary key lookups without cross-referencing these identifiers against the workspace or project context provided in the URL. This architectural inconsistency allows an authenticated user to bypass intended access controls by manipulating the estimate_id and issue_id parameters, thereby accessing data associated with workspaces and projects they do not own or have permission to view.
From a security taxonomy perspective, this vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key, which describes scenarios where an application uses user-supplied input as a key for authorization decisions without validating that the resource belongs to the expected context. Furthermore, in terms of offensive cyber operations and threat modeling, this flaw aligns with MITRE ATT&CK technique T1078: Valid Accounts, specifically within the sub-technique of abusing existing valid credentials to access unauthorized resources. The attacker leverages their legitimate authentication token but exploits the server-side logic failure to traverse across organizational boundaries defined by workspaces. This represents a significant breach of data isolation principles, as the application fails to enforce multi-tenancy constraints at the object level for these specific operations.
The operational impact of this vulnerability is severe due to its potential for both information disclosure and unauthorized modification. An authenticated attacker can read sensitive estimation data from other teams or organizations by simply altering the estimate identifier in a PATCH request, leading to confidentiality breaches regarding project timelines, resource allocation, and financial projections. Additionally, the ability to inject comments into issues belonging to other workspaces via the POST endpoint introduces integrity risks. This could be used for social engineering attacks, spreading misinformation within team workflows, or disrupting collaborative processes by posting unauthorized feedback on tasks that do not belong to the attacker's domain. The lack of scope verification means there is no audit trail linking these actions to a legitimate project context, complicating forensic analysis and incident response efforts.
Mitigation strategies must prioritize immediate patching as well as code-level remediation for any custom deployments or forks still running older versions. The primary fix involves ensuring that all API endpoints performing read, write, update, or delete operations on nested resources strictly validate the ownership of those resources against the workspace and project identifiers present in the request URL. Developers should refactor the estimate and comment handlers to join with their parent entities during database queries, verifying that the associated issue belongs to the specified project and that the project belongs to the specified workspace before processing any user input. Implementing a centralized authorization middleware or service can help enforce consistent permission checks across all endpoints, reducing the risk of similar inconsistencies in future development cycles. Regular security audits focusing on IDOR patterns are recommended to maintain robust access control mechanisms.