AshAuthentication CVE-2026-81637

Exploitation requires that the target application use AshAuthentication's OAuth2 (or OAuth2-derived) strategy via OAuth2.Plug.callback/2, versions 0.6.0 up to 4.15.0 or the 5.0.0-rc.0 to 5.0.0-rc.14 pre-releases. The attacker must (1) obtain the victim's stored OAuth2 state/session_params value, which only persists because a callback failure path (?error=access_denied, invalid code, token-exchange failure, or registration/sign-in failure) leaves delete_session unexecuted, and (2) induce the victim (UI:P/UI:R) to replay the callback within the same session before the next request phase or session expiry consumes the value. Limiting factors: the window is bounded by the session lifecycle, a specific callback failure must be induced to leave the state live, victim interaction is required, and the resulting impact is signing the victim into an attacker's account (login CSRF) rather than compromising the victim's own account.

This is a genuine but low-severity flaw. All exploitation signals point to minimal real-world risk: the vendor CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N) scores only 2.3, driven by high attack complexity (AC:H), an attack requirement (AT:P), passive user interaction (UI:P), and merely Low confidentiality/integrity impact with no availability impact. There is no CISA KEV listing and no public exploit code identified, so exploitation status is 'no public exploit identified at time of analysis.' No EPSS score was provided in the input, but the combination of a niche Elixir/Ash library, a multi-precondition attack, and low technical impact strongly implies a very low exploitation probability. The core weakness (CWE-613 Insufficient Session Expiration) is real and confirmed by the vendor's own commit diff - the with-chain rebinding of delete_session is skipped on every failure path - but the practical outcome is a login-CSRF/session-fixation where a victim is signed into an ATTACKER-controlled account, not account takeover of the victim. No signals conflict; every source (vendor advisory, ERLEF CNA, OSV) agrees on scope and low severity. This is a low-priority, fix-on-normal-cycle issue, not an emergency.

An attacker initiates an OAuth2 login flow, deliberately triggers a failure (e.g. cancels at the provider so it returns ?error=access_denied), and captures the still-valid stored state/session_params value, then lures the victim into replaying that callback so the victim is authenticated into the attacker's pre-seeded account. Any data the victim subsequently enters (linked profiles, uploads, notes) then lands in the account the attacker controls. No public exploit code exists, and the high complexity plus required victim interaction make opportunistic exploitation unlikely.