CVE-2026-104894 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, the modules endpoint accepts issue UUIDs in the URL path without validating that they belong to the caller's workspace. An authenticated user can link issues from any workspace to modules in their own workspace. This issue is fixed in 1.4.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/05/2026
The vulnerability identified in Plane, an open-source project management platform, represents a critical failure in server-side access control mechanisms within the application's module management functionality. Specifically, this flaw resides in how the backend API handles requests to associate issues with modules via the modules endpoint. The core technical deficiency is a lack of proper authorization checks regarding workspace ownership and data isolation boundaries. When an authenticated user submits a request containing issue UUIDs in the URL path for linking purposes, the application fails to verify whether those specific issues belong to the same workspace as the module being modified or even if they are accessible by the requesting user at all. This absence of validation allows for unauthorized cross-workspace data manipulation, effectively breaking the logical isolation that is fundamental to multi-tenant SaaS architectures and team-based project management tools.
From a technical perspective, this vulnerability classifies under CWE-284 Improper Access Control, specifically reflecting an authorization bypass where the application relies on client-supplied identifiers without enforcing server-side ownership constraints. The attacker exploits this by crafting HTTP requests that reference issue UUIDs from other workspaces to which they do not have legitimate access or affiliation. Because Plane prior to version 1.4.0 does not validate the workspace context of these referenced issues, it treats them as valid targets for association with modules within the attacker's own workspace. This behavior indicates a design flaw where the application assumes that if an issue UUID is syntactically correct and exists in the database, it can be linked by any authenticated user, ignoring the semantic relationship between users, workspaces, issues, and modules.
The operational impact of this vulnerability is significant for organizations relying on Plane to manage sensitive or segregated project data. An attacker with a valid account can inject external context into their own projects by linking issues from other teams or competitors' workspaces. This could lead to the leakage of confidential information if those linked issues contain descriptions, comments, attachments, or metadata that become visible within the attacker's module view. Furthermore, it compromises the integrity of project tracking and reporting metrics, as the workload distribution and progress indicators for modules may be artificially inflated with data from unrelated sources. In a multi-tenant environment, this also poses a risk to compliance requirements such as GDPR or HIPAA if personal health information or personally identifiable information is inadvertently exposed through these unauthorized links.
This type of vulnerability aligns closely with MITRE ATT&CK technique T1078 Valid Accounts and potentially T1534 Internal Spearphishing if used for social engineering contexts, but more accurately maps to CWE-639 Authorization Bypass Through User-Controlled Key in the context of API abuse. The exploitation requires only basic authentication, making it accessible to any registered user without needing elevated privileges or complex exploit chains. To mitigate this risk, organizations using versions prior to 1.4.0 should immediately upgrade to the patched version where the developers have implemented strict validation logic. This fix ensures that before an issue is linked to a module, the system verifies that both the issue and the target module belong to the same workspace associated with the authenticated user's permissions. Until upgrading is possible, administrators might consider restricting API access or implementing network-level controls if feasible, though patching remains the definitive remediation strategy for this logical flaw.