CVE-2026-104967 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, BulkDeleteIssuesEndpoint and SubIssuesEndpoint in apps/api/plane/app/views/issue/ accept body- or URL-supplied issue IDs and operate on them without checking that the IDs belong to the caller's workspace and project. The permission decorator on each endpoint validates only that the caller is a member or administrator of the workspace and project named in the URL. BulkDeleteIssuesEndpoint can destroy CycleIssue and ModuleIssue associations belonging to foreign issues. SubIssuesEndpoint can re-parent foreign issues under an attacker-selected issue and return the foreign issues' metadata. This issue is fixed in 1.4.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified involves a critical authorization flaw within Plane, an open-source project management platform, specifically affecting versions prior to 1.4.0. The core technical deficiency lies in the implementation of two API endpoints: BulkDeleteIssuesEndpoint and SubIssuesEndpoint located at apps/api/plane/app/views/issue/. These endpoints are designed to accept issue identifiers either through URL parameters or request body payloads. However, the server-side validation logic fails to verify that these supplied issue IDs actually belong to the workspace or project associated with the authenticated user's session. Instead of validating ownership based on the resource identifier provided in the payload, the permission decorator only checks if the caller is a member or administrator of the workspace and project specified in the URL path. This discrepancy creates a significant gap between identity verification and object-level authorization, allowing an attacker to manipulate resources outside their designated scope by simply altering the input parameters sent to these endpoints.
The operational impact of this flaw is severe due to its potential for both data destruction and information disclosure through unauthorized re-parenting operations. In the case of BulkDeleteIssuesEndpoint, an authenticated user can exploit the lack of ownership validation to delete CycleIssue and ModuleIssue associations belonging to issues that do not belong to their workspace or project. This effectively allows for the disruption of workflow structures and loss of organizational context for other users within the same instance. Furthermore, the SubIssuesEndpoint vulnerability enables a more subtle but equally damaging attack vector where an attacker can re-parent foreign issues under an issue they control. By doing so, the endpoint returns metadata associated with these unauthorized sub-issues to the attacker. This constitutes an information disclosure risk as it exposes details about projects and workflows that the user should not have access to, potentially revealing sensitive project structures or internal organizational hierarchies.
From a classification perspective, this vulnerability aligns directly with CWE-284, which describes Improper Access Control, specifically reflecting scenarios where authorization checks are bypassed by manipulating input parameters rather than relying on server-side resource ownership verification. It also maps to the MITRE ATT&CK framework under T1078, Valid Accounts, as it relies on legitimate authentication credentials but abuses their permissions through flawed logic, and potentially T1530, Data from Cloud Storage Object Misconfiguration if viewed in terms of accessing data outside intended boundaries. The root cause is a failure to implement proper object-level access control checks that bind the authenticated user's privileges strictly to the specific resources they are attempting to modify or read.
To mitigate this vulnerability, organizations running Plane versions prior to 1.4.0 must upgrade immediately to version 1.4.0 or later where these authorization logic errors have been corrected. For environments where immediate upgrading is not feasible, temporary mitigations should focus on restricting API access through network-level controls such as firewalls or reverse proxies that limit exposure of the affected endpoints to trusted internal networks only. Additionally, implementing strict input validation and ensuring that all backend service calls perform independent ownership verification against a secure database record before executing any destructive or data-revealing operations is essential. Developers should audit similar endpoint implementations across the application to ensure consistent enforcement of object-level permissions rather than relying solely on URL-based context for authorization decisions.