CVE-2026-104961 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, WorkspaceOwnerPermission does not require is_active=True when checking whether a user is a workspace owner. A deactivated user can therefore remain authorized as the workspace owner and retain owner-level access. 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 in Plane versions prior to 1.4.0 represents a critical authentication logic flaw within the application's role-based access control mechanism. Specifically, the WorkspaceOwnerPermission class failed to validate the active status of a user account when determining if that user holds workspace owner privileges. In standard security architectures, deactivating or disabling a user account should immediately revoke all associated permissions and access rights, effectively isolating the compromised identity from system resources. However, due to this oversight in the permission checking logic, the application continued to grant full administrative capabilities to users who had been explicitly deactivated by administrators. This discrepancy creates a significant gap between intended security policy and actual enforcement behavior, allowing previously disabled accounts to retain their highest level of authority within the workspace environment.
From a technical perspective, this flaw stems from an incomplete conditional check in the backend authorization layer. When requests are processed to verify if a user is a workspace owner, the system likely queries the database for role assignments but neglects to cross-reference the corresponding boolean flag indicating account activity status. Consequently, any request authenticated by a deactivated user's credentials or session token is treated as valid and authorized at the owner level. This behavior violates fundamental principles of identity lifecycle management, where access revocation must be immediate upon account deactivation regardless of other attributes such as role assignment history. The absence of this check means that administrative actions can still be executed by these inactive accounts, bypassing standard security controls designed to limit damage from compromised or terminated user identities.
The operational impact of this vulnerability is severe due to the elevated privileges associated with workspace owners. An attacker who has obtained credentials for a deactivated account could exploit this flaw to maintain persistent access to sensitive project data, modify configurations, manage team members, and potentially escalate their influence across other integrated systems connected to Plane. Since workspace owners typically have unrestricted control over projects, issues, cycles, and modules within the platform, the ability of an inactive user to act as such a role undermines the integrity of the entire collaboration environment. This could lead to unauthorized data exfiltration, malicious modification or deletion of critical project artifacts, and disruption of team workflows without detection by administrators who assume that deactivated accounts pose no threat.
This vulnerability aligns with CWE-269 Improper Privilege Management, as it involves a failure to properly restrict the actions an authenticated user can perform based on their current status. It also relates to CWE-754 Improper Check for Unusual or Exceptional Conditions, specifically regarding the handling of disabled accounts which are considered exceptional states that should trigger immediate access denial. In terms of MITRE ATT&CK framework techniques, this flaw facilitates Account Manipulation and potentially Persistence if an attacker uses a deactivated account as a backdoor to maintain long-term access while evading standard monitoring tools that might ignore inactive user activity logs. The lack of proper validation allows attackers to leverage stale credentials effectively, turning what should be a security measure into a liability.
To mitigate this risk, organizations using Plane must upgrade immediately to version 1.4.0 or later where the WorkspaceOwnerPermission logic has been corrected to enforce active status checks. For environments that cannot update instantly due to operational constraints, administrators should manually verify all workspace owner accounts and ensure no deactivated users retain ownership roles through database-level interventions if possible. Additionally, implementing strict session management policies that invalidate tokens upon account deactivation can provide an additional layer of defense against this specific logic flaw. Regular audits of user permissions and role assignments are recommended to detect any lingering unauthorized access patterns resulting from similar misconfigurations in other parts of the application's permission structure.