CVE-2026-105635 in Plane
Summary
by MITRE • 10/05/2026
Plane is an open-source project management tool. Prior to 1.4.0, ProjectJoinEndpoint at GET /api/workspaces/{slug}/projects/{project_id}/join/{pk}/ uses permission_classes = [AllowAny] and returns the full ProjectMemberInvite record, including its email, token, and role, to unauthenticated callers. The corresponding POST endpoint checks only whether the submitted email matches project_invite.email and does not validate the invitation token. An attacker who knows the invitation UUID can discover the invited email, register an account with that email, and accept the invitation without receiving the original invite. 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 prior to 1.4.0 represents a critical authentication bypass within its project management API infrastructure. Specifically, the GET endpoint for joining projects at /api/workspaces/{slug}/projects/{project_id}/join/{pk}/ was configured with permission_classes set to AllowAny. This configuration effectively removed any access control restrictions, allowing unauthenticated actors to query the system without providing valid credentials or session tokens. The consequence of this misconfiguration is that an attacker can retrieve the full ProjectMemberInvite record associated with a specific project invitation UUID. This response includes sensitive data fields such as the invited user's email address, the unique invitation token, and the assigned role within the workspace.
The severity of this information disclosure is compounded by the logic flaws present in the corresponding POST endpoint used to accept invitations. While the GET endpoint exposes the invite details, the acceptance mechanism only validates whether the submitted email address matches the one stored in the project_invite record. It fails to verify that the user submitting the request possesses or knows the actual invitation token required for secure redemption. This architectural oversight creates a scenario where knowledge of the UUID alone is sufficient to exploit the system. An attacker who obtains a valid invite UUID can query the GET endpoint to extract the target email address and then immediately submit a POST request with that email, successfully accepting the invitation without ever having received or interacted with the original email-based invitation link.
From an operational impact perspective, this vulnerability allows for unauthorized access to private project spaces. By exploiting this flaw, an attacker can join projects they were not explicitly invited to via standard channels, potentially gaining read and write permissions depending on the role assigned in the invite record. This leads to a breach of confidentiality as sensitive project data becomes accessible to unauthorized individuals. Furthermore, it undermines the integrity of the workspace by allowing malicious actors to inject themselves into collaborative environments, which can lead to further exploitation such as data exfiltration or sabotage. The ability to accept invitations without email verification also facilitates account takeover scenarios if users reuse passwords across platforms, although the primary impact here is unauthorized access rather than credential compromise.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials in terms of relying on predictable identifiers like UUIDs for security decisions without sufficient verification layers. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts, as it allows an attacker to use valid but unintended credentials or permissions to gain access to resources. The exploitation path involves Initial Access through discovery of invite identifiers and Privilege Escalation by assuming a role within the workspace without proper authorization checks.
To mitigate this vulnerability, organizations running Plane versions prior to 1.4.0 should upgrade immediately to version 1.4.0 or later where these issues have been addressed. The fix involves enforcing strict authentication requirements on the GET endpoint and implementing robust token validation in the POST acceptance flow. Until an upgrade is possible, administrators can implement a reverse proxy rule to block external access to the /api/workspaces/{slug}/projects/{project_id}/join/ endpoints or restrict them to internal networks only if applicable. Additionally, monitoring for unusual patterns of invitation acceptances from new IP addresses may help detect ongoing exploitation attempts in environments where patching is delayed.