CVE-2026-81632: Single-use sign-in token placed in a redirect query string in AshAuthenticationPhoenix
Use of HTTP Request With Sensitive Query String vulnerability in team-alembic AshAuthenticationPhoenix allows someone able to read access logs, proxy logs or browser history to recover a single-use sign-in token and authenticate as its owner.
After a successful password sign-in, AshAuthentication.Phoenix.Components.Password.SignInForm builds the signinwithtoken path with the freshly issued user.metadata.token as a query parameter and redirects the browser to it with a GET. The token therefore travels in the request line, where web servers, reverse proxies, request telemetry and the browser's own history record it, all of which outlive the request and are ordinarily less protected than session storage. The redirect destination is restricted to a local path, so this is not an open redirect; the exposure is the retention of a live credential.
This issue affects ashauthenticationphoenix: from 1.7.0 before 2.17.4 and from 3.0.0-rc.0 before 3.0.0-rc.11; ashauthentication: from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ash_authentication_phoenixto a version that resolves this vulnerability.Fixed in 2.17.4 - Upgrade
Upgrade
ash_authentication_phoenixto a version that resolves this vulnerability.Fixed in 3.0.0-rc.11 - Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 4.15.0 - Upgrade
Upgrade
ash_authenticationto a version that resolves this vulnerability.Fixed in 5.0.0-rc.14 - Operational
Assume any single-use sign-in tokens included in redirect query strings may have been exposed via access logs, proxy logs, request telemetry, or browser history; rotate/revoke any affected sessions/credentials as applicable after upgrading to the fixed versions.
Event History
Frequently Asked Questions
Who can exploit this issue in practice?
An attacker needs access to records that captured the redirected GET request, such as web-server, reverse-proxy, or request-telemetry logs, or to the affected browser's history. The captured single-use token can then be used to authenticate as the token owner.
Are applications using the normal password sign-in flow affected?
Yes. The issue occurs after a successful password sign-in, when the password sign-in form redirects to the sign_in_with_token path with the newly issued token in the query string.
Which versions need to be updated?
Update ash_authentication_phoenix to 2.17.4 or later in the 2.x line, or 3.0.0-rc.11 or later in the 3.x release-candidate line. Update ash_authentication to 4.15.0 or later in the 4.x line, or 5.0.0-rc.14 or later in the 5.x release-candidate line.
How can teams assess whether credentials may already have been exposed?
Review web-server, reverse-proxy, and request-telemetry logs, as well as browser histories where relevant, for sign_in_with_token requests containing a token query parameter. Those records may retain live sign-in credentials beyond the original request.