AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3 matches an existing account using the register action's upsert_identity keys, then gates linking the incoming provider identity to it on email_trusted?/2, which reads only the provider's email_verified boolean and never compares the provider's email value with the matched account's email. That gate assumes the account was matched by its email field, so under any other upsert_identity it is vacuous and an attacker presenting their own verified email is attached to, and issued a session for, an account matched on some other attribute. The same unguarded gate applies in OAuth2.SignInPreparation on the registration_enabled? false path, where the account is matched by the sign-in action's read filter instead. The upsert also rewrites the matched account's email to the attacker's address, so later account recovery reaches the attacker rather than the owner.
This issue affects ash_authentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| team-alembic | ash_authentication | unaffected |
|
|||||||||
| team-alembic | ash_authentication | unaffected |
|
No data.
No data.
No data.
No advisories yet.
Solution
Upgrading prevents new links but does not unpick existing ones. An account already linked through this path stays linked, and a victim's email may already have been rewritten to the attacker's address. Operators whose register action or sign-in action matched on anything other than the email should review their UserIdentity rows for links whose provider email does not match the linked account's email, and check affected accounts for a rewritten email address.
Workaround
Set trust_email_verified? false on the affected strategy, which refuses the sign-in rather than linking it and closes both the register and the sign-in path. Alternatively, key the register action's upsert_identity, or the sign-in action's read filter, on the email attribute, which restores the premise the gate assumes.
Thu, 17 Sep 2026 14:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Improper Authentication vulnerability in team-alembic AshAuthentication allows an attacker to be signed in as another user by linking an OAuth2 identity to an account that is not theirs. AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3 matches an existing account using the register action's upsert_identity keys, then gates linking the incoming provider identity to it on email_trusted?/2, which reads only the provider's email_verified boolean and never compares the provider's email value with the matched account's email. That gate assumes the account was matched by its email field, so under any other upsert_identity it is vacuous and an attacker presenting their own verified email is attached to, and issued a session for, an account matched on some other attribute. The same unguarded gate applies in OAuth2.SignInPreparation on the registration_enabled? false path, where the account is matched by the sign-in action's read filter instead. The upsert also rewrites the matched account's email to the attacker's address, so later account recovery reaches the attacker rather than the owner. This issue affects ash_authentication: from 4.14.0 before 4.15.0 and from 5.0.0-rc.10 before 5.0.0-rc.14. | |
| Title | OAuth2 sign-in attached to an existing account without an email comparison in AshAuthentication | |
| First Time appeared |
Team-alembic
Team-alembic ash Authentication |
|
| Weaknesses | CWE-287 | |
| CPEs | cpe:2.3:a:team-alembic:ash_authentication:*:*:*:*:*:*:*:* | |
| Vendors & Products |
Team-alembic
Team-alembic ash Authentication |
|
| References |
|
|
| Metrics |
cvssV4_0
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: EEF
Published:
Updated: 2026-09-17T14:15:19.506Z
Reserved: 2026-09-16T10:30:02.169Z
Link: CVE-2026-88952
Vulnrichment
No data.
NVD
Status : Received
Published: 2026-09-17T15:16:56.290
Modified: 2026-09-17T15:16:56.290
Link: CVE-2026-88952
Redhat
No data.
OpenCVE Enrichment
No data.