Summary
Pingvin Share X can improperly link an OAuth or OIDC identity to an existing account when the provider does not confirm that the email address is verified. A remote unauthenticated attacker who controls an enabled identity provider account using a victim's unverified email address may sign in as the victim, potentially including administrators, and bypass TOTP.
Pingvin Share X can improperly link an OAuth or OIDC identity to an existing account when the provider does not confirm that the email address is verified. A remote unauthenticated attacker who controls an enabled identity provider account using a victim's unverified email address may sign in as the victim, potentially including administrators, and bypass TOTP.
Affected context
The vulnerability occurs in Pingvin Share X deployments that enable OAuth or OIDC authentication and use the affected automatic email-linking behavior in OAuthService.signUp(). Risk is higher when an identity provider can issue email claims that are not verified, while GenericOidcProvider does not require an email_verified confirmation before associating the identity with an existing account.
The vulnerability occurs in Pingvin Share X deployments that enable OAuth or OIDC authentication and use the affected automatic email-linking behavior in OAuthService.signUp(). Risk is higher when an identity provider can issue email claims that are not verified, while GenericOidcProvider does not require an email_verified confirmation before associating the identity with an existing account.
Exploit preconditions
- Attack surface: Internet-facing OAuth or OIDC sign-in functionality
- Required access: No prior Pingvin Share authentication is generally required; the attacker needs an account or identity at an enabled provider that can present a victim's email address
- Trigger point: Automatic account creation or identity linking during OAuth sign-in
- Why exploitation is possible: The application may trust an email claim without confirming that the provider has verified ownership, allowing an external identity to be associated with an existing account
- Attack surface: Internet-facing OAuth or OIDC sign-in functionality
- Required access: No prior Pingvin Share authentication is generally required; the attacker needs an account or identity at an enabled provider that can present a victim's email address
- Trigger point: Automatic account creation or identity linking during OAuth sign-in
- Why exploitation is possible: The application may trust an email claim without confirming that the provider has verified ownership, allowing an external identity to be associated with an existing account
Why this happens
The underlying flaw is an authentication trust-boundary failure. During OAuth or OIDC registration and sign-in, the application uses an email claim to link identities without requiring a trustworthy verified-email signal from the provider.
This behavior maps to CWE-287: Improper Authentication, because account ownership is inferred from an insufficiently validated identity attribute. Treating an unverified email claim as proof of account control can allow authentication to an account that the requester does not own.
The underlying flaw is an authentication trust-boundary failure. During OAuth or OIDC registration and sign-in, the application uses an email claim to link identities without requiring a trustworthy verified-email signal from the provider.
This behavior maps to CWE-287: Improper Authentication, because account ownership is inferred from an insufficiently validated identity attribute. Treating an unverified email claim as proof of account control can allow authentication to an account that the requester does not own.
Potential impact
- An attacker may take over affected user accounts
- Administrative accounts could be compromised
- Attackers could bypass the account's normal TOTP requirement through the federated login path
- Unauthorized users may access, alter, or delete shared files and account data
- A compromised account could be used for further attacks against other users or connected services
- An attacker may take over affected user accounts
- Administrative accounts could be compromised
- Attackers could bypass the account's normal TOTP requirement through the federated login path
- Unauthorized users may access, alter, or delete shared files and account data
- A compromised account could be used for further attacks against other users or connected services
General mitigation guidance
Mitigation generally focuses on strengthening identity-provider trust decisions and preventing ambiguous automatic account linking.
Common defensive patterns include:
- Require a verified email claim, such as an authenticated
email_verifiedassertion, before linking an external identity to an existing account - Prefer stable, provider-scoped subject identifiers over email addresses for identity correlation
- Disable automatic linking when provider verification status is absent, inconsistent, or untrusted
- Require an explicit, authenticated account-linking workflow for existing accounts
- Preserve strong MFA requirements across federated authentication paths
- Limit OAuth/OIDC providers to those with documented identity and email-verification guarantees
- Apply least privilege to administrative accounts and review existing linked identities
Mitigation generally focuses on strengthening identity-provider trust decisions and preventing ambiguous automatic account linking.
Common defensive patterns include:
- Require a verified email claim, such as an authenticated
email_verifiedassertion, before linking an external identity to an existing account - Prefer stable, provider-scoped subject identifiers over email addresses for identity correlation
- Disable automatic linking when provider verification status is absent, inconsistent, or untrusted
- Require an explicit, authenticated account-linking workflow for existing accounts
- Preserve strong MFA requirements across federated authentication paths
- Limit OAuth/OIDC providers to those with documented identity and email-verification guarantees
- Apply least privilege to administrative accounts and review existing linked identities
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for account linking based solely on email claims
- Review of OAuth/OIDC handlers for enforcement of
email_verifiedand validation of issuer, audience, and subject claims - Tests covering unverified, missing, conflicting, and provider-specific email claims
- Monitoring for unexpected new OAuth identities linked to existing accounts
- Alerts on administrative account sign-ins through newly linked providers or unusual identity-provider patterns
- Policy enforcement that requires explicit approval for external identity linking
Automated security review tools may help identify authentication flows that trust user-controlled or insufficiently verified identity attributes.
Organizations can look for this class of issue through:
- Static analysis and code review checks for account linking based solely on email claims
- Review of OAuth/OIDC handlers for enforcement of
email_verifiedand validation of issuer, audience, and subject claims - Tests covering unverified, missing, conflicting, and provider-specific email claims
- Monitoring for unexpected new OAuth identities linked to existing accounts
- Alerts on administrative account sign-ins through newly linked providers or unusual identity-provider patterns
- Policy enforcement that requires explicit approval for external identity linking
Automated security review tools may help identify authentication flows that trust user-controlled or insufficiently verified identity attributes.
