ash_authentication

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

Details

Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.

3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.

Configurations

Exploitation requires one of:

• The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
• The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.

Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.

PoC

1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.

Impact

Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.

References

• Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
• Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
• Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

Details

Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.

3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.

Configurations

Exploitation requires one of:

• The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
• The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.

Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.

PoC

1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.

Impact

Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.

References

• Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
• Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
• Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

Details

Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.

3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.

Configurations

Exploitation requires one of:

• The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
• The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.

Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.

PoC

1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.

Impact

Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.

References

• Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
• Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
• Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

Details

Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.

3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.

Configurations

Exploitation requires one of:

• The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
• The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.

Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.

PoC

1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.

Impact

Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.

References

• Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
• Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
• Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

Details

Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.

3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.

Configurations

Exploitation requires one of:

• The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
• The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.

Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.

PoC

1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.

Impact

Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.

References

• Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
• Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
• Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

Details

Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.

3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.

Configurations

Exploitation requires one of:

• The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
• The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.

Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.

PoC

1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.

Impact

Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.

References

• Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
• Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
• Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

Details

Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.

3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.

Configurations

Exploitation requires one of:

• The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
• The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.

Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.

PoC

1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.

Impact

Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.

References

• Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
• Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
• Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

Details

Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.

3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.

Configurations

Exploitation requires one of:

• The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
• The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.

Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.

PoC

1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.

Impact

Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.

References

• Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
• Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
• Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.

Summary

Improper Neutralization of Input During Web Page Generation (XSS) vulnerability in team-alembic AshAuthentication allows reflected cross-site scripting via the confirmation and magic link interaction forms.

When a strategy is configured with require_interaction? set to true, AshAuthentication serves an intermediate HTML page asking the user to confirm the action by submitting a form. Both such pages embed a request parameter directly into a hidden input's value attribute without HTML escaping: 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. These templates are compiled with EEx.function_from_file/3 using plain <%= %> expressions, which perform no escaping, so the parameter is reflected verbatim.

Neither accept handler validates the value before rendering it. AshAuthentication.AddOn.Confirmation.Plug.accept/2 only checks that a confirm key is present, and AshAuthentication.Strategy.MagicLink.Plug.accept/2 reads the parameter directly, so no token signature is verified at this stage and arbitrary attacker-supplied text reaches the template. An unauthenticated attacker can therefore craft a URL whose parameter terminates the attribute and injects markup, for example a quote followed by a <script> element. Because the accept phase is served over GET, loading the crafted link is sufficient; no form submission or prior authentication is required.

The injected script executes in the origin of the application embedding AshAuthentication, giving it access to that origin's cookies, session, and same-origin responses. Since these pages are part of the authentication flow, a victim following what appears to be a legitimate confirmation or sign-in link is a plausible target.

This 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.

Configurations

Only strategies configured with require_interaction? set to true are affected. This option defaults to false, and when it is disabled the vulnerable accept route is not registered at all, so the affected pages cannot be reached.

The option is not obscure: AshAuthentication's own documentation for the confirmation add-on advises that applications using AshAuthenticationPhoenix should enable it, so the affected configuration is a documented and recommended deployment rather than an unusual one.

At least one of the following must be configured with require_interaction? true:

• the confirmation add-on, which serves the affected confirmation accept form; or
• the magic_link strategy, which serves the affected sign-in accept form.

Summary

AshAuthentication's OAuth2 and OIDC family strategies matched the local user by email address rather than by the OpenID Connect iss/sub claim combination. A provider login presenting a victim's email (including an unverified, reused, or email_verified: false account) resolved to and signed in as the victim's existing local account. An unauthenticated attacker who can register an account on any accepted OAuth provider with the victim's email obtains the victim's full local privileges.

Details

Per OpenID Connect Core §5.7, only the iss/sub claim combination uniquely and stably identifies an end-user; any other claim, including email, MUST NOT be used as a unique identifier. AshAuthentication's OAuth2/OIDC register flow nonetheless drove the upsert by the email field (upsert_identity on email, or a user-defined sign-in filter), and the sign-in preparation filtered users by email.

1. Provider login. The attacker signs in to a configured OAuth/OIDC provider with the victim's email. This is trivial for providers that don't verify email ownership, and possible under email-reuse / reclamation for providers that do.

2. AshAuthentication register step. 'Elixir.AshAuthentication.Strategy.OAuth2.IdentityChange':change/3 invokes the upsert action whose upsert_identity resolves on the email. The action lands on the victim's existing record.

3. Sign-in preparation. 'Elixir.AshAuthentication.Strategy.OAuth2.SignInPreparation':prepare/3 does not verify the returned user against an iss/sub identity, so the attacker is authenticated as the victim.

Configurations

Exploitation requires one of:

• The configured OAuth/OIDC provider does not reliably verify email ownership (lets a user register with any email, or fails to verify it). Many social/enterprise providers fall into this category, including Slack, generic OIDC deployments, and any custom OAuth2 endpoint without strict email validation.
• The provider allows email reclamation: the victim's email becomes available on the provider (account deletion, organisation off-boarding, mail-host change) and the attacker registers it. The attacker then signs in via that provider and takes over the local account.

Providers that strictly verify email ownership and forbid reuse (e.g. modern Google Workspace, GitHub for accounts that have completed verification) are not directly exploitable, but applications that accept any of the affected strategy types in addition are still exposed via the weaker providers in the set.

PoC

1. On any accepted OAuth/OIDC provider, register an account whose email is the victim's email (or use a provider that allows email reuse).
2. Complete the standard OAuth flow against the AshAuthentication application.
3. The application's upsert resolves on email, signs the attacker in as the victim, and returns a session token for the victim's account.

Impact

Unauthenticated remote account takeover against any AshAuthentication-using application that exposes an OAuth2/OIDC strategy. The default configuration of every affected strategy is vulnerable; no application-level misconfiguration is required. An attacker who succeeds gains the victim's full local identity, with read, write, and destructive access to whatever the victim's account can do.

References

• Introduction commit: https://github.com/team-alembic/ash_authentication/commit/c5f589058e04239263f50a1430eb17ea6d5dd1a2
• Patch commit (4.x backport): https://github.com/team-alembic/ash_authentication/commit/728b8d28c1b5f465fa1116ef044a815300fc733d
• Patch commit (5.x): https://github.com/team-alembic/ash_authentication/commit/64530644f9b37ebb76ca14aeb83a77597a0034b7

Summary

Improper Authentication vulnerability in team-alembic AshAuthentication allows purpose-limited JWTs to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification.

The bearer-token authentication helper AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 verifies an Authorization: Bearer JWT's signature and rejects tokens containing an act claim, but performs no check that the token's purpose claim equals user at the bearer boundary. When the resource is configured with require_token_presence_for_authentication?: false (the DSL default), the follow-on validate_token/3 helper returns {:ok, nil} without consulting the token resource, so no downstream check on purpose takes place either. As a result, any valid, non-expired JWT the library itself issued for a narrow, single-purpose flow (most notably the purpose: sign_in token that WebAuthn always emits during sign-in, and that the Password strategy emits when sign-in tokens are enabled) is accepted directly as a general-purpose bearer credential and resolves to a full current_user assignment.

This bypasses the library's intended token-exchange contract, in which the sign_in token is meant to be presented exactly once to a preparation that validates the purpose claim and immediately revokes the token. The first use of a still-valid sign-in token presented directly in the Authorization header succeeds because the stateless bearer path never scopes it to purpose == "user".

An attacker who obtains a not-yet-exchanged sign-in token for a target subject (for example via log or referrer leakage, an intercepted magic-link delivery channel, or a partially compromised intermediary) can present it as a bearer token and be authenticated as that subject, fully bypassing the intended one-time-use and revocation semantics. Exploitation additionally requires that the host application wire up retrieve_from_bearer/3 on a reachable route and uses either WebAuthn (sign-in tokens are always issued) or the Password strategy with sign_in_tokens_enabled?: true. Resources configured with require_token_presence_for_authentication?: true (including applications scaffolded by the Igniter installer since v4.5.0) and the session-based path (authenticate_resource_from_session/4) enforce purpose == "user" against the stored token record and are not affected.

This issue affects ash_authentication: from 3.10.5 before 4.14.2 and from 5.0.0-rc.0 before 5.0.0-rc.13.

Configurations

The bypass is reachable only when a resource uses stateless bearer-token verification, i.e. require_token_presence_for_authentication? is false (the DSL default). In that mode validate_token/3 returns {:ok, nil} without consulting the token resource, so the JWT's purpose claim is the only remaining scoping signal at the bearer boundary and it is never checked. When require_token_presence_for_authentication? is true, validate_token/3 looks the token up with get_token(%{"jti" => jti, "purpose" => "user"}); purpose-limited tokens are stored under their own purpose (sign_in, remember_me, ...), so that lookup fails and those tokens are rejected. Applications scaffolded by the Igniter installer since v4.5.0 default to require_token_presence_for_authentication?: true and are therefore not exposed as generated; applications configured manually or that deliberately opt into stateless JWT verification are.

Exploitation additionally requires the host application to wire up AshAuthentication.Plug.Helpers.retrieve_from_bearer/3 on a route the attacker can reach, and to use a strategy that issues purpose-limited JWTs carrying a resolvable sub claim: either the WebAuthn strategy (sign-in tokens are always emitted, no opt-in required) or the Password strategy with sign_in_tokens_enabled?: true. The session-based path (authenticate_resource_from_session/4) already enforces purpose == "user" against the token resource and is not affected.