OAuth2 sign-in attached to an existing account without an email comparison in AshAuthentication
Published Sep 17, 2026 · Updated 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.
Summary
What happened
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.
The record
- CVE
- CVE-2026-88952
- Published
- Sep 17, 2026
- Updated
- Sep 17, 2026
- Vendor
- Alembic
- Product
- Ash Authentication
- Classifications
- Unavailable
- Attack vector
- Unavailable
- Privileges
- Unavailable
Timeline
How it unfolded
- Sep 17, 2026CVE publishedPublication date reported by the CVE source.
- Sep 17, 2026Record updatedLatest update available in the CVE record.
Exploitability
Present is not the same as exploitable
Compare your product and version with the public record. A matching version still requires validation against your environment.
Is a vulnerable build present?
Compare these published version ranges with your installed build and any vendor patches.
- Affected versionversion=4.14.0 <4.15.0
- Affected versionversion=42edcd8ebb13fafbb168f12591d7518ce0611fec <* changes=[{"at":"738bf9f32f2aa0d1bb92ce9ca5c2476cb5710459","status":"unaffected"},{"at":"2bd630eef8b7c8ae1e90e8fd43ba12fbc7e256ba","status":"unaffected"}]
- Affected versionversion=5.0.0-rc.10 <5.0.0-rc.14
- Affected versionversion=64530644f9b37ebb76ca14aeb83a77597a0034b7 <* changes=[{"at":"738bf9f32f2aa0d1bb92ce9ca5c2476cb5710459","status":"unaffected"},{"at":"2bd630eef8b7c8ae1e90e8fd43ba12fbc7e256ba","status":"unaffected"}]
What conditions does exploitation require?
What is affected?
Published CVSS scores
No CVSS assessment is available in this record.
CVSS describes severity. EPSS estimates exploitation probability.
Attacks
What attackers are doing with it
Daily unique IPs observed by Shadowserver honeypots for known exploited vulnerabilities (KEVs). Missing observations do not establish an absence of attacks.
Activity data is delayed. The latest report is Sep 28, 2026.
Weakness, pattern, technique
No sourced classifications are available.
Public exploit references
No public exploit references are available in this record.
Labels summarize the accepted research assessment. They do not indicate a test against your environment.
Technologies
Your stack
See the directory against your own environment.
Your stack
Check the software in your environment
Get started to see how Hinoki identifies affected software and validates exploitability in your environment.
Get started