CVE-2026-105632 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, the GraphQL joinProject mutation lets any workspace member add themselves to any project in that workspace including network=0 (secret/private) projects they were never invited to and grants them a full Member role (read + write). The resolver checks only workspace-level membership/role and never checks the target project's visibility (network). This collapses project-level tenant isolation within a workspace: a low-privilege member can read and modify confidential data in every private project. 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, an open-source project management platform, represents a critical failure in access control logic that undermines the fundamental security principle of tenant isolation within multi-tenant workspaces. Specifically, this flaw resides in the GraphQL joinProject mutation, which is designed to allow users to request membership or be added to specific projects within their workspace. Prior to version 1.4.0, the backend resolver responsible for processing these requests performed an insufficient authorization check. The system verified only that the requesting user was a valid member of the overarching workspace but completely neglected to validate whether the target project had restricted visibility settings, such as being marked as private or secret with network access set to zero. This oversight allowed any authenticated workspace member, regardless of their specific role within individual projects, to arbitrarily add themselves to any project in that workspace without an explicit invitation from a project administrator.
From a technical perspective, this issue is classified under CWE-284, Improper Access Control, and aligns with the MITRE ATT&CK technique T1078, Valid Accounts, as it involves leveraging legitimate credentials to access resources beyond their intended scope. The core of the flaw lies in the application's failure to enforce project-level permissions independently from workspace-level permissions. In a properly secured architecture, even if a user has broad access at the organizational or workspace level, they should not automatically inherit read and write privileges for private projects unless explicitly granted by the project owners. By bypassing these granular checks, the vulnerability effectively collapses the boundary between public collaboration spaces and confidential workspaces, allowing low-privilege members to escalate their rights silently.
The operational impact of this vulnerability is severe due to the full Member role it grants upon successful execution. A malicious actor or a compromised account with basic workspace membership can read sensitive project data, modify tasks, alter timelines, and potentially exfiltrate confidential information from private projects they were never invited to join. This breach of confidentiality compromises not only individual privacy but also organizational integrity, as trade secrets, strategic plans, or personal employee data stored in these private projects become accessible to unauthorized individuals. The lack of audit trails for such self-added memberships further exacerbates the risk, making it difficult for administrators to detect and remediate the intrusion promptly.
To mitigate this vulnerability, organizations using Plane versions prior to 1.4.0 must upgrade immediately to version 1.4.0 or later, where the resolver has been patched to correctly check target project visibility before granting access. For environments that cannot be upgraded instantly due to operational constraints, temporary mitigations include restricting workspace membership to only trusted individuals and enabling enhanced logging if available to monitor for unusual joinProject activity. Additionally, administrators should review existing private projects to ensure no unauthorized members have gained access through this flaw during the window of exposure. Regular security audits focusing on role-based access control consistency across different levels of hierarchy are recommended to prevent similar logical flaws in future deployments or customizations of the platform.