CVE-2026-104970 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. From 0.13 until 1.4.0, InstanceAdminSignUpEndpoint in apps/api/plane/license/api/views/admin.py:89-117, 173-229 uses InstanceAdmin.objects.first() for the first-admin check and performs account creation without an atomic transaction, row lock, uniqueness guard, or advisory lock. Two concurrent unauthenticated requests with different email addresses can both observe that no instance administrator exists, create separate User and InstanceAdmin rows, and receive sessions with instance-admin authority. This allows an attacker to share unrestricted instance administration with the legitimate operator. 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 versions from 0.13 through 1.4.0 represents a critical race condition within the initial administrative account provisioning process, specifically located in the InstanceAdminSignUpEndpoint of the application's API layer. This flaw stems from a fundamental lack of concurrency control during the creation of the first instance administrator, which is intended to be a singular role with unrestricted access to all system resources and configurations. The core technical deficiency lies in the method used to determine whether an admin account already exists; the code relies on InstanceAdmin.objects.first() to check for existing administrators without implementing any form of database-level locking or atomic transactional integrity. This approach creates a classic time-of-check-to-time-of-use (TOCTOU) vulnerability where the state verification and the subsequent state modification are not executed as an indivisible unit, allowing multiple concurrent processes to observe the same initial state before either has completed its write operation.
When two unauthenticated requests arrive simultaneously with different email addresses, both threads or processes will query the database for existing instance administrators. Since no administrator exists at that precise moment, both queries return null or empty results, leading each request to proceed under the assumption that it is creating the sole first admin. Because there are no row locks, advisory locks, or unique constraints enforced during this specific creation phase, both requests successfully execute their respective INSERT operations for User and InstanceAdmin records. Consequently, two distinct user accounts are created with full instance administrator privileges, effectively bypassing the intended security model that restricts such high-level access to a single designated operator.
The operational impact of this vulnerability is severe, as it allows an attacker who can send concurrent requests during the initial setup phase to gain unauthorized administrative control over the Plane instance. This results in a complete compromise of system integrity and availability, as multiple actors possess unrestricted authority to modify settings, manage projects, access sensitive data, or potentially escalate privileges further within the application ecosystem. The ability for an external party to share this unrestricted administration undermines trust in the platform's security posture and could lead to significant data breaches or malicious manipulation of project management workflows if exploited in a production environment before proper hardening measures are applied.
This issue is classified under CWE-362, which describes concurrent execution using shared resources with less than adequate synchronization, specifically highlighting the failure to use atomic operations for critical state changes. In terms of offensive security frameworks, this aligns with MITRE ATT&CK techniques related to privilege escalation and account manipulation, where an adversary exploits a race condition to gain unauthorized access levels that should be strictly controlled. The vulnerability was addressed in version 1.4.0 by implementing proper concurrency controls, likely involving database-level unique constraints on the admin role or transactional isolation mechanisms such as row locking or advisory locks to ensure that only one request can successfully create the first administrator account at any given time. Organizations running affected versions should upgrade immediately and review their deployment scripts to ensure that initial setup processes are not susceptible to similar race conditions during automated provisioning scenarios.