Answer in brief
CVE-2026-88952 records a Critical severity (CVSS 9.1) vulnerability in OAuth2 sign-in attached to an existing account without an email comparison in AshAuthentication. The current sources do not mark it as known exploited. The current feed maps team-alembic/ash_authentication (generic), team-alembic/ash_authentication (generic), team-alembic/team-alembic/ash_authentication (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 9.1. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps team-alembic/ash_authentication (generic), team-alembic/ash_authentication (generic), team-alembic/team-alembic/ash_authentication (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| team-alembic/ash_authenticationgeneric | >=64530644f9b37ebb76ca14aeb83a77597a0034b7 <* || >=42edcd8ebb13fafbb168f12591d7518ce0611fec <* | * |
| team-alembic/ash_authenticationgeneric | >=4.14.0 <4.15.0 || >=5.0.0-rc.10 <5.0.0-rc.14 | 4.15.0, 5.0.0-rc.14 |
| team-alembic/team-alembic/ash_authenticationgeneric | >=64530644f9b37ebb76ca14aeb83a77597a0034b7 <* || >=42edcd8ebb13fafbb168f12591d7518ce0611fec <* | * |
Published upstream
Sep 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 18, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 17, 2026
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.
Quoted source text, attributed separately from HOL analysis.