Summary
Plane exposes project invitation details, including the invited email, token, and role, to unauthenticated callers and does not properly validate the invitation token when accepting an invite. An attacker who knows an invitation identifier may therefore join a project without receiving the original invitation.
Plane exposes project invitation details, including the invited email, token, and role, to unauthenticated callers and does not properly validate the invitation token when accepting an invite. An attacker who knows an invitation identifier may therefore join a project without receiving the original invitation.
Affected context
The vulnerability occurs in Plane project invitation endpoints when invitation records are exposed through an unauthenticated GET request and acceptance relies on matching an email address rather than proving possession of the invitation token. Deployments are at risk when invitation identifiers are discoverable or otherwise obtainable and the affected endpoint behavior is present.
The vulnerability occurs in Plane project invitation endpoints when invitation records are exposed through an unauthenticated GET request and acceptance relies on matching an email address rather than proving possession of the invitation token. Deployments are at risk when invitation identifiers are discoverable or otherwise obtainable and the affected endpoint behavior is present.
Exploit preconditions
- Attack surface: HTTP API endpoints for project invitations
- Required access: No authenticated access is required to query the invitation endpoint; the invitation UUID must be known or discovered
- Trigger point: Retrieval and subsequent acceptance of a project invitation
- Why exploitation is possible: The read endpoint permits unauthenticated access and discloses invitation attributes, while the acceptance flow checks the email address without validating the invitation token
- Attack surface: HTTP API endpoints for project invitations
- Required access: No authenticated access is required to query the invitation endpoint; the invitation UUID must be known or discovered
- Trigger point: Retrieval and subsequent acceptance of a project invitation
- Why exploitation is possible: The read endpoint permits unauthenticated access and discloses invitation attributes, while the acceptance flow checks the email address without validating the invitation token
Why this happens
The underlying issue is an authorization and object-level access-control failure. The invitation retrieval endpoint uses an allow-all permission policy and returns sensitive fields from a project membership invitation, while the acceptance endpoint treats an email match as sufficient proof of authorization. This behavior maps primarily to CWE-862: Missing Authorization, with related exposure and authorization weaknesses represented by CWE-200 and CWE-284.
The underlying issue is an authorization and object-level access-control failure. The invitation retrieval endpoint uses an allow-all permission policy and returns sensitive fields from a project membership invitation, while the acceptance endpoint treats an email match as sufficient proof of authorization. This behavior maps primarily to CWE-862: Missing Authorization, with related exposure and authorization weaknesses represented by CWE-200 and CWE-284.
Potential impact
- An attacker may learn the email address associated with a project invitation
- An attacker may accept an invitation without receiving the original invite
- An attacker may obtain unauthorized membership in a project
- Exposed invitation tokens could be reused or disclosed to other parties
- Project data and collaboration functions may become accessible to an unauthorized account
- An attacker may learn the email address associated with a project invitation
- An attacker may accept an invitation without receiving the original invite
- An attacker may obtain unauthorized membership in a project
- Exposed invitation tokens could be reused or disclosed to other parties
- Project data and collaboration functions may become accessible to an unauthorized account
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every invitation operation and requiring proof of possession of the invitation secret.
Common defensive patterns include:
- Require a valid, unexpired invitation token for both retrieval and acceptance
- Avoid exposing invitation emails, tokens, roles, or other sensitive fields to unauthenticated callers
- Use narrowly scoped authorization checks for the workspace, project, and invitation object
- Treat email matching as an additional consistency check rather than the authorization credential
- Apply single-use semantics, expiration, and revocation to invitation tokens
- Return minimized responses and avoid distinguishable errors that reveal invitation existence
- Run invitation-related operations with the least privilege necessary
Mitigation generally focuses on enforcing authorization at every invitation operation and requiring proof of possession of the invitation secret.
Common defensive patterns include:
- Require a valid, unexpired invitation token for both retrieval and acceptance
- Avoid exposing invitation emails, tokens, roles, or other sensitive fields to unauthenticated callers
- Use narrowly scoped authorization checks for the workspace, project, and invitation object
- Treat email matching as an additional consistency check rather than the authorization credential
- Apply single-use semantics, expiration, and revocation to invitation tokens
- Return minimized responses and avoid distinguishable errors that reveal invitation existence
- Run invitation-related operations with the least privilege necessary
How teams detect issues like this
Detection can include:
- Static analysis and code review checks for allow-all permission policies on sensitive endpoints
- Searches for invitation acceptance logic that compares identity attributes without validating a cryptographic or server-issued token
- API tests verifying that unauthenticated users cannot enumerate invitation data
- Authorization tests covering cross-workspace, cross-project, expired, revoked, and reused invitations
- Monitoring for repeated invitation lookups, failed token attempts, and acceptance from unexpected accounts or locations
- Policy enforcement requiring object-level authorization and response-field minimization for invitation APIs
Detection can include:
- Static analysis and code review checks for allow-all permission policies on sensitive endpoints
- Searches for invitation acceptance logic that compares identity attributes without validating a cryptographic or server-issued token
- API tests verifying that unauthenticated users cannot enumerate invitation data
- Authorization tests covering cross-workspace, cross-project, expired, revoked, and reused invitations
- Monitoring for repeated invitation lookups, failed token attempts, and acceptance from unexpected accounts or locations
- Policy enforcement requiring object-level authorization and response-field minimization for invitation APIs
