Plane EUVD-2026-92700

The attacker must know (or obtain) the UUID 'pk' of a pending ProjectMemberInvite record for a target project in Plane < 1.4.0 - this is the primary prerequisite and the reason complexity is High rather than Low, since UUIDs are not enumerable by default. Given a valid invite UUID, no authentication is required (the GET endpoint uses permission_classes=[AllowAny]) and it works against default configurations: the GET leaks the invitee email, role, and acceptance token, and the POST accept path validates only that the submitted email matches project_invite.email while failing to validate the invitation token. Limiting factors: exploitation is bounded to projects that currently have outstanding (unaccepted) invitations whose UUIDs the attacker can reference, and the attacker must be able to register an account with the disclosed email address.

Signals are moderately consistent and point to a genuine but condition-gated risk. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, base 7.4 High) correctly captures that the GET endpoint is unauthenticated (PR:N via AllowAny) and network-reachable, but rates complexity High (AC:H) - which is appropriate because exploitation hinges on the attacker first knowing the invitation's UUID (the pk), a value that is not enumerable by default. No EPSS score, SSVC decision, or KEV entry was supplied in the input, and there is no POC flag, so exploitation status is: no public exploit identified at time of analysis. The only exploitation evidence is the vendor fix (PR #9305, commit 4b52dce, release v1.4.0) confirming the flaw and its mechanics. This is a real, authentic priority for anyone running self-hosted Plane < 1.4.0 - the vulnerability is confirmed by the vendor's own security advisory (GHSA-2r58-hgv7-635q) and the leaked email+token enables invitation hijacking - but it is not a mass-exploitable internet-worm scenario because the attacker must already possess a valid invite UUID. Missing data to note explicitly: no EPSS/KEV/SSVC were provided, so widespread-exploitation likelihood cannot be quantified from the input; absence of these is not evidence of low risk, only of unmeasured risk.

An attacker who has learned or guessed a pending project-invite UUID (e.g., from a leaked/forwarded invite link, logs, or referrer) calls the unauthenticated GET /api/workspaces/{slug}/projects/{project_id}/join/{pk}/ endpoint and reads back the invitee's email, role, and acceptance token. They then register a new account using that disclosed email and POST to the join endpoint, which validates only the email match and not the token, letting them accept the invitation and join the target project with the intended role. No public exploit code was identified, but the vendor's patch diff fully documents the flaw mechanics.