CVE-2026-105639 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, Plane's signup flow creates a logged-in User row for any submitted email without an out-of-band ownership check, while User.email is unique=True. The authenticated user can call GET /api/users/me/workspaces/invitations/, which returns each WorkspaceMemberInvite whose email matches request.user.email. WorkSpaceMemberInviteSerializer uses fields = "all", exposing the token that protects the invitation join endpoint. An unauthenticated attacker who knows a target's email can register an account using that address, enumerate pending invitations, and accept an invitation as the target, joining a workspace at the invited role. The term pre-auth describes the attacker's initial state: the attacker has no credential before signup, while the enumeration and join requests use the session created by that signup. 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
Plane version 1.3.x and earlier contain a critical authentication bypass vulnerability within its user registration workflow that allows unauthenticated attackers to hijack pending workspace invitations intended for specific email addresses. The root cause lies in the application's signup logic, which automatically creates a logged-in User row associated with any submitted email address without performing an out-of-band ownership verification such as sending a confirmation link or requiring OTP validation before establishing session state. Because the User.email field is defined with unique constraints, this mechanism effectively allows anyone to claim identity over an existing or future user account simply by submitting that email during registration. This design flaw fundamentally undermines the assumption of identity integrity at the point of entry, creating a persistent authenticated session for the attacker under the victim's email identifier immediately upon signup completion.
The operational impact is severe due to how Plane handles workspace invitations and their associated tokens. Once an unauthenticated actor registers using a target's known email address, they obtain a valid authentication token linked to that identity. The application exposes an endpoint at GET /api/users/me/workspaces/invitations/, which returns all WorkspaceMemberInvite objects where the invitee's email matches the currently authenticated user's email. Crucially, the serialization of these invitation objects includes sensitive security credentials, specifically the unique token required to accept the invitation and join the workspace. This data exposure means that an attacker does not need to guess or brute-force any additional secrets; they can directly retrieve the acceptance tokens for all pending invitations assigned to the victim's email address through a simple authenticated API call.
This vulnerability enables a pre-authentication attack scenario where no prior credentials are required from the adversary. By leveraging the session established during the malicious signup, an attacker can enumerate every pending workspace invitation associated with the target and subsequently accept them using the exposed tokens. This results in unauthorized access to private or restricted workspaces at whatever role was originally assigned by the invitee's administrator. The attacker gains full operational capabilities within those workspaces, including viewing sensitive project data, collaborating on tasks, and potentially escalating privileges depending on the invited role. Since this process relies entirely on API interactions that mimic legitimate user behavior, it may evade basic anomaly detection systems that do not specifically monitor for rapid registration followed by immediate invitation acceptance patterns.
From a standards perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-598 Use of GET Request to Do Sensitive Operations if the enumeration is considered sensitive data exposure, though it more precisely fits CWE-640 Weakness in Out-of-Band Control for Identity Verification. In terms of MITRE ATT&CK, this behavior maps to T1078 Valid Accounts and specifically T1136 Create Account, as the attacker creates a valid account under another's identity to gain initial access. The subsequent enumeration and acceptance of invitations can be classified under T1528 Steal Application Access Token if viewed through the lens of token misuse, although here the tokens are legitimately exposed by the API design rather than stolen via injection or interception.
Mitigation strategies must address both the registration flow and the data exposure in serialization layers. The primary fix implemented in version 1.4.0 involves enforcing an out-of-band ownership check during signup, ensuring that a user cannot establish an authenticated session until they prove control over the email address through external verification methods such as click-through confirmation links or one-time passwords. Additionally, API serializers should be audited to ensure that sensitive tokens and security credentials are never included in response payloads for endpoints intended for enumeration purposes. Implementing rate limiting on registration attempts per IP address can also help mitigate bulk exploitation efforts. Organizations running versions prior to 1.4.0 should upgrade immediately or apply temporary compensating controls such as disabling public self-registration if feasible, thereby preventing attackers from creating the initial authenticated sessions required to exploit this flaw.