AshAuthentication EUVD-2026-36714

The target application must (a) use ash_authentication at a vulnerable version (0.1.0-4.13.x or 5.0.0-rc.0-rc.9) and (b) have at least one OAuth2 or OIDC family strategy enabled (Auth0, Apple, generic OAuth2, or OIDC) that the attacker can complete a sign-in against. The attacker must be able to present the victim's email to that provider - by registering on a provider that allows arbitrary or unverified email addresses, exploiting provider-side email reuse or reclamation, or using a provider that returns email_verified: false. No user interaction from the victim is required, no prior authentication to the target application is required, and the victim's local account need not have ever used the OAuth provider. Deployments restricted to password or magic-link strategies are not exploitable.

CVSS 4.0 of 9.2 (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H) is justified: exploitation is network-reachable, unauthenticated, and yields full takeover of the victim's local account with whatever privileges that account holds. The AT:P (attack requirements present) qualifier correctly reflects that the attacker needs the application to have an OAuth2/OIDC strategy enabled and to accept a provider on which the attacker can obtain the victim's email - a real but readily achievable precondition given how many public OIDC providers allow unverified emails or email reclamation. No EPSS, KEV, or POC data is supplied, so this is no public exploit identified at time of analysis; however, the bug class is conceptually identical to the Microsoft/Nextcloud/Grafana OIDC-email-takeover issues, so weaponization difficulty is low for any attacker who can identify a vulnerable deployment. Real-world priority should be HIGH for any application using ash_authentication with a federated provider, and LOW only for deployments that use ash_authentication exclusively with password or magic-link strategies.

An attacker identifies a target application using ash_authentication with, for example, an Auth0 or generic OIDC sign-in button, looks up a victim's email address (often public), and registers a fresh account on an accepted OAuth provider using that email - or uses a provider that does not verify email ownership at all. The attacker clicks 'Sign in with <provider>', and because AshAuthentication matches by email rather than (iss, sub), the session is bound to the victim's pre-existing local account with full privileges. No public proof-of-concept is referenced, but the attack requires only a browser and a free provider account.