CVE-2026-66882: AshAuthentication XSS Vulnerability

CVE-2026-66882 Overview

CVE-2026-66882 is a reflected cross-site scripting (XSS) vulnerability in the team-alembic ash_authentication library for Elixir. The flaw affects intermediate HTML pages served during confirmation and magic link flows when a strategy is configured with require_interaction? set to true. Both forms interpolate a request parameter directly into a hidden input's value attribute without HTML escaping, allowing an unauthenticated attacker to inject markup via a crafted URL. The injected script executes in the origin of the application embedding AshAuthentication, giving it access to cookies, session data, and same-origin responses. The issue affects ash_authentication from 4.8.0 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Critical Impact
An unauthenticated attacker can execute arbitrary JavaScript in the victim's browser under the application origin by luring the victim to click a crafted confirmation or magic link URL.

Affected Products

team-alembic ash_authentication4.8.0 through versions before 4.14.2
team-alembic ash_authentication5.0.0-rc.0 through versions before 5.0.0-rc.13
Elixir applications embedding AshAuthentication with strategies configured using require_interaction?: true

Discovery Timeline

2026-08-25 - CVE-2026-66882 published to NVD
2026-08-25 - Last updated in NVD database

Technical Details for CVE-2026-66882

Vulnerability Analysis

The vulnerability is a reflected cross-site scripting flaw classified under CWE-79. When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page prompting the user to confirm the action by submitting a form.

Two templates embed a request parameter directly into a hidden input's value attribute without HTML escaping. The file lib/ash_authentication/add_ons/confirmation/confirmation_form.html.eex interpolates the confirm parameter, and lib/ash_authentication/strategies/magic_link/sign_in_form.html.eex interpolates the magic link token parameter. Both templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping.

Because the accept phase is served over GET, loading the crafted link alone triggers execution. The injected script runs in the application's origin, exposing cookies, session state, and same-origin responses.

Root Cause

The root cause is missing HTML output encoding in two EEx templates. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only verifies that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly. Neither handler validates the value or verifies a token signature before rendering, so attacker-supplied text reaches the template verbatim.

Attack Vector

An unauthenticated attacker crafts a URL whose confirm or token parameter terminates the value attribute with a quote and injects markup such as a <script> element. The victim clicks what appears to be a legitimate confirmation or sign-in link. Because these pages are part of the authentication flow, the social-engineering pretext is plausible. No form submission or prior authentication is required.

text

   <body>
     <h1>Confirm your account</h1>
 
-    <form method="post" action="<%= @conn.request_path %>">
-      <input type="hidden" name="confirm" value="<%= @token %>" />
+    <form method="post" action="<%= Plug.HTML.html_escape(@conn.request_path) %>">
+      <input type="hidden" name="confirm" value="<%= Plug.HTML.html_escape(to_string(@token)) %>" />
       <input type="submit" value="Confirm" />
     </form>
   </body>

Source: GitHub commit 0bd5199. The patch wraps both interpolated values with Plug.HTML.html_escape/1 to neutralize markup before rendering.

Detection Methods for CVE-2026-66882

Indicators of Compromise

HTTP GET requests to AshAuthentication confirmation or magic link accept endpoints containing quote characters, angle brackets, or <script> fragments in the confirm or token parameter.
Referer chains where users arrive at authentication endpoints from external domains carrying long, URL-encoded query strings.
Web server logs showing atypically long or encoded values for confirm or token parameters that do not match the expected token format.

Detection Strategies

Inspect access logs for requests to routes handled by AshAuthentication.AddOn.Confirmation.Plug and AshAuthentication.Strategy.MagicLink.Plug and flag parameters containing <, >, ", or %3C.
Add a Web Application Firewall (WAF) rule matching XSS payload patterns against the confirm and token query parameters.
Correlate authentication endpoint anomalies with subsequent session or account-takeover events to identify successful exploitation.

Monitoring Recommendations

Alert on repeated failed confirmation or magic link attempts from a single source with malformed parameters.
Monitor outbound requests from authenticated user sessions to unexpected domains, indicating possible session exfiltration.
Track Content Security Policy (CSP) violation reports for inline script executions on authentication pages.

How to Mitigate CVE-2026-66882

Immediate Actions Required

Upgrade ash_authentication to 4.14.2 or later on the 4.x branch, or to 5.0.0-rc.13 or later on the 5.x release candidate branch.
Audit application configuration to identify strategies where require_interaction? is set to true and prioritize patching those deployments.
Invalidate active sessions if log review identifies exploitation attempts against the affected endpoints.

Patch Information

The fix is provided in commits 0bd5199 and 6271971, which wrap the interpolated @token and @conn.request_path values with Plug.HTML.html_escape/1 in both confirmation_form.html.eex and sign_in_form.html.eex. See the GitHub Security Advisory GHSA-54fc-x3hv-ffhw and the Erlef CNA record for full details.

Workarounds

Set require_interaction? to false where compatible with the application's UX requirements to bypass rendering of the vulnerable intermediate pages.
Deploy a strict Content Security Policy (CSP) that disallows inline scripts on authentication routes to reduce the impact of injected markup.
Add server-side validation in front of AshAuthentication that rejects confirm and token parameters not matching the expected token format before they reach the plug.

bash

# Update ash_authentication in mix.exs, then fetch the patched release
# mix.exs
# {:ash_authentication, "~> 4.14.2"}

mix deps.update ash_authentication
mix deps.get
mix compile