Summary
Plane can incorrectly trust an email address supplied by certain OAuth providers and match it directly to an existing local account. If an attacker can control an unverified provider email claim, they may sign in to another user's Plane account without knowing that user's password.
Plane can incorrectly trust an email address supplied by certain OAuth providers and match it directly to an existing local account. If an attacker can control an unverified provider email claim, they may sign in to another user's Plane account without knowing that user's password.
Affected context
The vulnerability occurs in Plane installations using OAuth integrations where the identity provider does not cryptographically or administratively confirm email ownership. It is relevant to Gitea OAuth and self-managed GitLab deployments with email confirmation disabled; providers that return verified email addresses are not generally affected by this specific trust issue.
The vulnerability occurs in Plane installations using OAuth integrations where the identity provider does not cryptographically or administratively confirm email ownership. It is relevant to Gitea OAuth and self-managed GitLab deployments with email confirmation disabled; providers that return verified email addresses are not generally affected by this specific trust issue.
Exploit preconditions
- Attack surface: Plane's OAuth login and account-linking or account-matching flow
- Required access: An attacker needs an OAuth identity accepted by a configured provider and control over the identity's unverified email attribute
- Trigger point: Plane matches the provider-supplied email address to an existing local account during authentication
- Why exploitation is possible: The application treats an unverified provider claim as proof of ownership without independently validating the email or requiring an established account association
- Attack surface: Plane's OAuth login and account-linking or account-matching flow
- Required access: An attacker needs an OAuth identity accepted by a configured provider and control over the identity's unverified email attribute
- Trigger point: Plane matches the provider-supplied email address to an existing local account during authentication
- Why exploitation is possible: The application treats an unverified provider claim as proof of ownership without independently validating the email or requiring an established account association
Why this happens
The underlying flaw is an authentication trust-boundary failure. Plane accepts an email value from an OAuth provider and uses it as an account identifier even when the provider has not confirmed that the user controls that address. This maps primarily to CWE-287: Improper Authentication, with CWE-290: Authentication Bypass by Spoofing also relevant because an attacker can impersonate an account by presenting a conflicting identity attribute.
The underlying flaw is an authentication trust-boundary failure. Plane accepts an email value from an OAuth provider and uses it as an account identifier even when the provider has not confirmed that the user controls that address. This maps primarily to CWE-287: Improper Authentication, with CWE-290: Authentication Bypass by Spoofing also relevant because an attacker can impersonate an account by presenting a conflicting identity attribute.
Potential impact
- An attacker may gain unauthorized access to a victim's Plane account
- Private projects, issues, documents, and related workspace data could be exposed
- Account content may be modified, deleted, or used to affect project operations
- The compromised account could be used to access connected integrations or target other workspace members
- An attacker may gain unauthorized access to a victim's Plane account
- Private projects, issues, documents, and related workspace data could be exposed
- Account content may be modified, deleted, or used to affect project operations
- The compromised account could be used to access connected integrations or target other workspace members
General mitigation guidance
Mitigation generally focuses on treating OAuth email claims as untrusted unless the provider explicitly verifies ownership.
Common defensive patterns include:
- Accepting only provider assertions that include a verified-email claim with an authenticated meaning
- Avoiding automatic account matching based solely on an email address
- Requiring an existing authenticated session or explicit account-linking confirmation before associating identities
- Using stable provider subject identifiers rather than mutable email attributes for identity binding
- Applying least privilege to OAuth-linked accounts and connected integrations
- Preserving strong local authentication and recovery controls for accounts created or linked through OAuth
Mitigation generally focuses on treating OAuth email claims as untrusted unless the provider explicitly verifies ownership.
Common defensive patterns include:
- Accepting only provider assertions that include a verified-email claim with an authenticated meaning
- Avoiding automatic account matching based solely on an email address
- Requiring an existing authenticated session or explicit account-linking confirmation before associating identities
- Using stable provider subject identifiers rather than mutable email attributes for identity binding
- Applying least privilege to OAuth-linked accounts and connected integrations
- Preserving strong local authentication and recovery controls for accounts created or linked through OAuth
How teams detect issues like this
Organizations can look for this class of issue through:
- Static and dynamic review of OAuth callback handlers and account-linking logic
- Code-review signals where provider-supplied email values directly select local accounts
- Tests covering unverified, changed, duplicate, and conflicting email claims
- Identity-provider policy checks that require confirmed email ownership
- Authentication logs showing first-time OAuth identities accessing pre-existing accounts
- Automated security review rules that flag account matching without verified claims or explicit linking
Organizations can look for this class of issue through:
- Static and dynamic review of OAuth callback handlers and account-linking logic
- Code-review signals where provider-supplied email values directly select local accounts
- Tests covering unverified, changed, duplicate, and conflicting email claims
- Identity-provider policy checks that require confirmed email ownership
- Authentication logs showing first-time OAuth identities accessing pre-existing accounts
- Automated security review rules that flag account matching without verified claims or explicit linking
