The vulnerability allows an attacker who controls one identity‑provider connection of a dynamic_oidc strategy in the ash_authentication component to authenticate as any user established through a different connection. This occurs because the identity records are not namespaced by connection; the strategy name stored in UserIdentity rows omits the connection identifier, so the unique key (uid, strategy) collapses all users across connections into a single namespace. The result is that an attacker can exploit an existing user’s subject identifier (sub) from their own connection to impersonate that user on another connection, bypassing all authentication checks and gaining unauthorized access to the target user’s account. The impact is a full account takeover, which compromises confidentiality, integrity, and availability for the affected users.

Affected systems are deployments of team‑alembic ash_authentication from version 5.0.0‑rc.10 up to but not including 5.0.0‑rc.14. The patch fixes this issue in version 5.0.0‑rc.14 and later. Deployments using dynamic_oidc identity‑provider connections must also run the included database migration to re‐link existing UserIdentity rows to the correct namespaced strategy value. Systems with a single connection can simply upgrade and apply the migration, whereas systems with multiple connections must perform additional audits described in the workaround. Unknown or unsupported versions outside this range are not affected according to the CNA entry.

With a CVSS score of 9.1, this issue falls in the critical severity range. The EPSS score is not available, indicating insufficient data to assess current exploitation probability, but the lack of mention in the CISA KEV catalog suggests that it is not yet a known widespread exploit. The attack vector is inferred to be remote authentication via the OIDC provider, as the vulnerability is triggered when an attacker supplies a valid subject identifier from their own connection. An attacker who can create or control a connection on the affected system can immediately obtain a pre‑signed identity token for that subject and log in as the target user. Unless the deployment applies the upgrade and performs a migration and audit, the risk is high and the vulnerability remains exploitable.