James Harton

**Name of the Vulnerable Software and Affected Versions** ash authentication versions 3.10.5 through 4.14.1 ash authentication versions 5.0.0-rc.0 through 5.0.0-rc.12 **Description** Improper authentication allows purpose-limited JSON Web Tokens (JWTs) to be replayed as full bearer API credentials when a resource uses stateless bearer-token verification. The helper function `retrieve from bearer/3` verifies the signature of an Authorization: Bearer JWT and rejects tokens with an `act` claim, but fails to verify if the token's `purpose` claim equals `user`. When the resource is configured with `require token presence for authentication?` set to `false`, the `validate token/3` helper returns `{:ok, nil}` without consulting the token resource, bypassing downstream purpose checks. Consequently, valid, non-expired JWTs issued for narrow purposes—such as the `sign in` token emitted by WebAuthn or the Password strategy—are accepted as general-purpose bearer credentials, granting full `current user` assignment. An attacker who obtains a valid `sign in` token can authenticate as the target subject, bypassing one-time-use and revocation semantics. This requires the application to use `retrieve from bearer/3` on a reachable route and employ either WebAuthn or the Password strategy with `sign in tokens enabled?` set to `true`. **Recommendations** Update ash authentication to version 4.14.2 or later. Update ash authentication to version 5.0.0-rc.13 or later. Set `require token presence for authentication?` to `true` to enforce purpose verification against the stored token record. Restrict access to routes utilizing the `retrieve from bearer/3` helper function.

**Name of the Vulnerable Software and Affected Versions** ash authentication versions 4.8.0 through 4.14.1 ash authentication versions 5.0.0-rc.0 through 5.0.0-rc.12 **Description** Reflected cross-site scripting (XSS) occurs when a strategy is configured with `require interaction?` set to true. The software serves intermediate HTML pages that embed request parameters directly into hidden input value attributes without HTML escaping. Specifically, the `confirm` parameter is interpolated in `lib/ash authentication/add ons/confirmation/confirmation form.html.eex` and the magic link token parameter is interpolated in `lib/ash authentication/strategies/magic link/sign in form.html.eex`. Because these templates use plain expressions that perform no escaping and the `accept/2` functions in `AshAuthentication.AddOn.Confirmation.Plug` and `AshAuthentication.Strategy.MagicLink.Plug` do not validate the values, an unauthenticated attacker can craft a URL to inject malicious markup. The injected script executes in the application origin, allowing access to cookies, sessions, and same-origin responses. **Recommendations** Update ash authentication to version 4.14.2 or later. Update ash authentication to version 5.0.0-rc.13 or later.

**Name of the Vulnerable Software and Affected Versions** ash authentication versions 0.1.0 through 4.13.x ash authentication versions 5.0.0-rc.0 through 5.0.0-rc.9 **Description** An authentication bypass by spoofing allows account takeover of local users during OAuth2 or OIDC sign-in. The issue occurs because the software matches local users by email address instead of using the OpenID Connect `iss` (issuer) and `sub` (subject) claim combination, which are the only stable and unique identifiers for an end-user. An unauthenticated attacker can register an account on an accepted OAuth provider using a victim's email—including unverified or reused emails—to gain full local privileges of the victim's account. **Recommendations** Update versions 0.1.0 through 4.13.x to version 4.14.0. Update versions 5.0.0-rc.0 through 5.0.0-rc.9 to version 5.0.0-rc.10.

**Name of the Vulnerable Software and Affected Versions** ash-project ash authentication phoenix versions prior to 2.10.0 **Description** The issue affects the ash authentication phoenix library, where session tokens remain valid on the server after a user logs out. This creates a security gap where compromised tokens can continue to work, even after the user logs out. The sessions stored in the database still expire, limiting the duration during which this could be exploited. Users cannot fully invalidate their sessions when logging out from shared or potentially compromised devices. However, changing one's password does invalidate all other sessions. This may cause compliance issues with security frameworks requiring complete session invalidation. **Recommendations** Upgrade to version 2.10.0. After upgrading, update the AuthController implementation to use the new `clear session/2` function with the OTP app name. If the setting `require token presence for authentication?` is not set to `true` in the `tokens` section, enable it if possible, or set `authentication.session identifier` to `:jti`. Note that setting `require token presence for authentication?` to `true` or setting `authentication.session identifier` to `:jti` will log out all currently authenticated users if this was not previously configured. As a temporary workaround, manually revoke tokens in the `logout/2` handler in the auth controller.