Summary
Plane's signup flow can create an authenticated account for an email address without verifying that the registrant controls that address. An attacker who knows a target's email may obtain invitation details and accept a pending workspace invitation as that user, potentially gaining the invited role.
Plane's signup flow can create an authenticated account for an email address without verifying that the registrant controls that address. An attacker who knows a target's email may obtain invitation details and accept a pending workspace invitation as that user, potentially gaining the invited role.
Affected context
The issue occurs in Plane deployments where signup does not include an out-of-band email ownership check, email addresses are unique user identifiers, and authenticated users can retrieve invitations associated with their account email. The risk is greatest when pending workspace invitations contain sensitive joining tokens in API responses.
The issue occurs in Plane deployments where signup does not include an out-of-band email ownership check, email addresses are unique user identifiers, and authenticated users can retrieve invitations associated with their account email. The risk is greatest when pending workspace invitations contain sensitive joining tokens in API responses.
Exploit preconditions
- Attack surface: Public signup combined with authenticated user and
workspace-invitation API endpoints
- Required access: Knowledge of the target user's email address; no
credential is required before account creation
- Trigger point: Account registration followed by invitation enumeration
and invitation acceptance using the resulting session
- Why exploitation is possible: The application treats an
unverified email as the user's identity and exposes invitation-protection
tokens in a response associated with that email
- Attack surface: Public signup combined with authenticated user and
workspace-invitation API endpoints
- Required access: Knowledge of the target user's email address; no
credential is required before account creation
- Trigger point: Account registration followed by invitation enumeration
and invitation acceptance using the resulting session
- Why exploitation is possible: The application treats an
unverified email as the user's identity and exposes invitation-protection
tokens in a response associated with that email
Why this happens
The underlying flaw is an insufficient identity-verification boundary in the signup process. Plane creates a logged-in user for a submitted email before confirming ownership, then uses that unverified value to authorize access to matching workspace invitations. Returning all invitation fields, including a security-sensitive token, further enables unauthorized use of the invitation. This primarily maps to CWE-287: Improper Authentication, with related exposure and authorization concerns represented by CWE-200 and CWE-639.
The underlying flaw is an insufficient identity-verification boundary in the signup process. Plane creates a logged-in user for a submitted email before confirming ownership, then uses that unverified value to authorize access to matching workspace invitations. Returning all invitation fields, including a security-sensitive token, further enables unauthorized use of the invitation. This primarily maps to CWE-287: Improper Authentication, with related exposure and authorization concerns represented by CWE-200 and CWE-639.
Potential impact
- An attacker may join a workspace using another person's pending invitation
- The attacker could receive the role assigned to the intended invitee
- Workspace data and project resources may be exposed
- Unauthorized membership could enable modification of project content
- Invitation tokens may be disclosed through overly broad API serialization
- An attacker may join a workspace using another person's pending invitation
- The attacker could receive the role assigned to the intended invitee
- Workspace data and project resources may be exposed
- Unauthorized membership could enable modification of project content
- Invitation tokens may be disclosed through overly broad API serialization
General mitigation guidance
Mitigation generally focuses on verifying email ownership before granting authenticated identity privileges and separating invitation access from unverified profile attributes. Invitation tokens should be treated as sensitive capabilities, excluded from general-purpose serializers, and usable only through narrowly scoped, server-side authorization checks. Systems should bind invitations to verified identities or require an explicit, secure acceptance flow, minimize returned fields, invalidate tokens after use, and apply least privilege to newly joined members. Rate limiting, audit logging, and controls against account and invitation enumeration can provide additional protection.
Mitigation generally focuses on verifying email ownership before granting authenticated identity privileges and separating invitation access from unverified profile attributes. Invitation tokens should be treated as sensitive capabilities, excluded from general-purpose serializers, and usable only through narrowly scoped, server-side authorization checks. Systems should bind invitations to verified identities or require an explicit, secure acceptance flow, minimize returned fields, invalidate tokens after use, and apply least privilege to newly joined members. Rate limiting, audit logging, and controls against account and invitation enumeration can provide additional protection.
How teams detect issues like this
Detection approaches include static and API review checks for signup flows that authenticate users before email verification, authorization decisions based solely on submitted email values, and serializers that expose complete database models. Code review should inspect invitation lookup, token issuance, acceptance, and invalidation paths for identity binding and privilege checks. Dynamic testing can compare access to invitation data before and after email verification, while policy enforcement can flag sensitive tokens in API responses and require explicit authorization tests for membership endpoints. Automated security review tools may help identify these patterns during development.
Detection approaches include static and API review checks for signup flows that authenticate users before email verification, authorization decisions based solely on submitted email values, and serializers that expose complete database models. Code review should inspect invitation lookup, token issuance, acceptance, and invalidation paths for identity binding and privilege checks. Dynamic testing can compare access to invitation data before and after email verification, while policy enforcement can flag sensitive tokens in API responses and require explicit authorization tests for membership endpoints. Automated security review tools may help identify these patterns during development.
