CVE-2026-104964 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, Plane's project update endpoint authorizes the caller against the workspace slug in the request URL but loads the target project globally by UUID without binding it to that workspace. An administrator of one workspace can modify a project in another workspace when the victim project UUID is known. This violates tenant isolation and permits unauthorized cross-workspace changes to project metadata and configuration. 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 in Plane, an open-source project management platform, represents a critical failure in access control logic that undermines the fundamental principle of multi-tenant isolation. Prior to version 1.4.0, the application's architecture for handling project updates contained a significant logical flaw within its authorization mechanism. The system was designed to manage multiple distinct workspaces, each intended to operate as an isolated environment with strict boundaries preventing users from one workspace from interfering with another. However, the implementation of these boundaries relied on inconsistent validation methods that failed to enforce proper context binding between the user's current session and the target resource being modified.
The technical root cause lies in how the project update endpoint validates permissions. When a request is made to modify a project, the application checks the authorization against the workspace slug present in the URL path. This check confirms whether the authenticated caller has administrative privileges within that specific workspace context. However, despite this initial validation step, the actual retrieval and modification of the target project resource are performed using only the globally unique identifier (UUID) associated with the project. The application fails to verify that the UUID provided corresponds to a project actually belonging to the workspace identified by the slug in the request URL. This decoupling of authorization context from resource identification creates a direct path for unauthorized access, as the system trusts the client-supplied UUID without cross-referencing it against the validated workspace boundaries.
This architectural flaw results in a severe impact on data integrity and confidentiality through cross-workspace tampering. An attacker who possesses administrative rights within one valid workspace can exploit this vulnerability by crafting requests that target projects located in entirely different workspaces, provided they know or can guess the UUID of those external projects. By submitting an update request with their own workspace slug but a victim project's UUID, the administrator bypasses tenant isolation controls. This allows them to modify sensitive metadata, alter configuration settings, and potentially disrupt operations within other organizations' environments using Plane. The ability to manipulate resources outside one's designated scope violates core security principles regarding data segregation and can lead to significant operational disruptions for affected tenants who rely on strict separation of their project management activities.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing proper authorization checks relative to the resource context. It also maps closely to MITRE ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate credentials within one domain or tenant to perform actions outside their authorized scope by exploiting logical flaws rather than credential theft. The issue highlights a common pitfall in web application development where developers may assume that checking permissions against the current context is sufficient without ensuring that all resource identifiers are bound to that same context during data retrieval and mutation operations.
To mitigate this vulnerability, organizations running Plane prior to version 1.4.0 must upgrade immediately to the patched release which corrects the authorization logic by binding project lookups strictly to the validated workspace scope. For environments where immediate upgrading is not feasible due to operational constraints, temporary mitigations should focus on restricting access to the affected endpoints through network-level controls or web application firewalls that validate both the workspace slug and project UUID consistency before allowing requests to reach the application backend. Additionally, implementing rigorous input validation at the API layer to ensure that any resource identifier passed in a request is verified against the authorized scope of the authenticated user's current session can provide an additional layer of defense. Regular security audits focusing on access control logic are recommended to identify similar patterns where authorization checks and resource identification mechanisms are not tightly coupled, ensuring robust tenant isolation across all multi-tenant features.