Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-10-05T17:17:12.937Z",
  "pubdate": "2026-10-05T17:17:12.937Z",
  "executiveSummary": "Plane versions 0.13 through 1.4.0 are vulnerable to a race condition in the InstanceAdminSignUpEndpoint, allowing unauthorized privilege escalation.\nThe vulnerability arises from a lack of atomicity and locking mechanisms during the initial instance administrator registration process.\nAn unauthenticated attacker can exploit this flaw by sending concurrent requests to create multiple administrative accounts, effectively bypassing the single-admin constraint.\nSuccessful exploitation results in the attacker gaining unrestricted instance administration privileges, granting full control over the application instance.\nThis vulnerability is particularly critical as it allows an attacker to compromise a legitimate deployment by gaining persistent administrative access alongside or instead of the intended operator.\nThe risk is high due to the ease of exploitation, requiring only standard HTTP request capabilities and no prior authentication.",
  "technicalDetails": "The vulnerability is located in the InstanceAdminSignUpEndpoint within apps/api/plane/license/api/views/admin.py, specifically between lines 89-117 and 173-229.\nThe root cause is a classic Time-of-Check to Time-of-Use (TOCTOU) race condition. The application relies on InstanceAdmin.objects.first() to verify if an administrator account already exists. However, this check is performed without implementing database-level synchronization primitives such as atomic transactions, row-level locking (SELECT FOR UPDATE), or advisory locks.\nBecause the check and the subsequent creation of the User and InstanceAdmin records are decoupled, the application state remains vulnerable between the execution of the check and the write operation.\nThe attack flow proceeds as follows: 1. An attacker identifies that no administrator has been registered yet. 2. The attacker triggers two or more near-simultaneous unauthenticated HTTP requests to the sign-up endpoint, each providing different credentials. 3. Because the application logic does not lock the table or row during the verification phase, both requests simultaneously execute InstanceAdmin.objects.first() and observe that the result is null. 4. Consequently, both requests proceed to the creation logic. 5. The application creates separate User and InstanceAdmin records for both requests. 6. Both requests receive valid session tokens with instance-admin privileges, despite the design intent that only one such administrator should exist.\nThis vulnerability allows an attacker to inject their own administrative account into an instance that may otherwise appear to be awaiting setup by a legitimate user. By successfully racing the legitimate setup process, the attacker ensures they are provisioned with full administrative access to the platform, enabling them to configure, monitor, or exfiltrate data from the application instance. The issue persists until the application logic is updated to ensure that the check and registration operations are performed as a single, atomic database transaction with appropriate concurrency controls."
}