James Harton

A session fixation issue allows an attacker to maintain an authenticated session if they can plant a session identifier in a victim's browser before the victim signs in. This occurs because the function `store in session/2` in `AshAuthentication.Plug.Helpers` uses `Plug.Conn.put session/3` to write the authenticated subject without calling `Plug.Conn.configure session(renew: true)`, causing the pre-authentication identifier to persist. This affects the default `success/4` function in `AshAuthentication.Phoenix.Controller. using /1`, the `AuthController` from `mix ash authentication phoenix.install`, and remember-me auto-login. Additionally, the `clear session/2` function uses `Plug.Conn.clear session/1`, which removes session content but keeps the identifier, allowing a planted ID to survive a logout-then-login sequence. In deployments using server-side session stores (such as ETS, Mnesia, Redis, or a database), this can lead to full account takeover. This is possible if the attacker can plant a cookie via sibling subdomain cookie tossing, an HTTP host without HSTS, or a shared browser.

Insufficient session expiration allows a revoked session to remain fully authenticated. When a resource is configured with `session identifier :jti` and `require token presence for authentication?` is disabled, the session value is stored as `<jti>:<subject>`. The functions `AshAuthentication.Plug.Helpers.authenticate resource from session/4` and `AshAuthentication.Phoenix.LiveSession.on mount/4` use `split identifier/2` to discard the `jti` and pass only the subject to `AshAuthentication.subject to user/3`. Since the revocation record is not consulted, the revoked state and expiry of the `jti` are ignored, allowing sessions captured before sign-out to remain active.

An improper authentication issue allows an attacker to sign in as another user by linking an OAuth2 identity to an account that does not belong to them. The `AshAuthentication.Strategy.OAuth2.UserResolver.resolve/3` function matches an existing account using `upsert identity` keys and validates the link via `email trusted?/2`. However, this check only verifies the provider's `email verified` boolean and fails to compare the provider's email value with the matched account's email. This flaw also exists in `OAuth2.SignInPreparation` when `registration enabled?` is false and the account is matched by the sign-in action's read filter. An attacker with a verified email from a provider can be issued a session for an account matched on a different attribute. Additionally, the process rewrites the matched account's email to the attacker's address, allowing the attacker to intercept future account recovery attempts.

An authentication bypass by spoofing exists in the `dynamic oidc` strategy. This allows an attacker using one identity-provider connection to be signed in as a local user associated with a different connection. The issue occurs because the intended identity namespacing, which should format the `strategy` field of `UserIdentity` rows as `"<name>/<connection id>"`, is not applied. Instead, the ` connection id ` variable is only populated on an ephemeral runtime struct and is not used during the identity change process in the `DynamicOidc.IdentityChange.change/3` function. Consequently, the system falls back to the bare strategy name for identity writes and reads in `oauth2/user resolver.ex` and `oauth2/sign in preparation.ex`. Because the unique key for the identity resource is `(uid, strategy)` and the system does not handle the `iss` (issuer) claim, users from different providers with the same `sub` (subject) value are treated as the same user. This can lead to account takeover without victim interaction or the silent merging of distinct users who happen to share the same subject identifier across different providers.

An authentication bypass by spoofing allows an attacker to replace a victim's authenticated session with their own account by planting a remember-me cookie in the victim's browser. This occurs because the function `sign in using remember me/3` checks the session for a `<subject name> token` key to avoid re-authenticating already-signed-in users. However, the `store in session/2` function only writes this key when `require token presence for authentication?` is enabled; otherwise, it writes only the subject name. Under default settings, the guard reads a key that is never written, causing the remember-me sign-in process to run on every request. Consequently, a planted cookie is honored even if a live session exists, leading the victim to unknowingly enter data into an account controlled by the attacker. This discrepancy exists because the read path in `authenticate resource from session/4` selects the key correctly, while the guard does not.

Improper verification of cryptographic signatures in AshAuthentication allows a caller of the token revocation action to neutralize a revocation or write arbitrary rows into the token resource. The function `AshAuthentication.TokenResource.RevokeTokenChange.change/3` reads the `:token` argument and decodes it using `AshAuthentication.Jwt.peek/1`, which delegates to `Joken.peek claims/1` without performing a signature check. Consequently, the `jti`, `exp`, and `sub` claims are written directly to the revocation record. An attacker can provide a forged token with a backdated `exp` claim, causing the revocation row to be treated as expired and removed by `expunge expired`, which allows the genuine token to pass the `revoked?` check. Additionally, arbitrary `jti` and `sub` values can be inserted into the resource.

Improper authentication allows an attacker with a sign-in token for one authenticated resource to be signed in as a user of a different resource. The function `extract primary keys from subject/2` within `AshAuthentication.Strategy.Password.SignInWithTokenPreparation` parses the JWT `sub` claim using `URI.parse/1` and retains only the query string, discarding the path segment that identifies the subject for which the token was issued. Because `AshAuthentication.Jwt.verify/3` only validates the signature and specific claims (`exp`, `nbf`, `jti`, and library-version) without restoring the resource binding, and primary-key field names are identical across resources, the authentication is bypassed. This behavior also affects WebAuthn sign-in and remember-me preparations. The magic link sign-in path is not affected.

An issue in AshAuthenticationPhoenix allows an attacker with access to access logs, proxy logs, or browser history to recover a single-use sign-in token and authenticate as the token owner. This occurs because `AshAuthentication.Phoenix.Components.Password.SignInForm` constructs the `sign in with token` path using the `user. metadata .token` as a query parameter and performs a GET redirect. Consequently, the token is recorded in the request line by web servers, reverse proxies, and browser history, exposing a live credential in locations that are typically less secure than session storage.

Insufficient session expiration allows an attacker who obtains a victim's OAuth2 `state` value to replay the callback and sign that victim into an attacker-controlled account. The function `AshAuthentication.Strategy.OAuth2.Plug.callback/2` fails to clear stored `session params` during failure paths, such as when the provider returns an access denied error, an invalid code, or a token-exchange error. Because the `else` block in the Elixir `with` chain reaches `store authentication result/2` while holding the original connection, the session entry is not removed. Consequently, the value intended to protect against Cross-Site Request Forgery (CSRF) is only consumed upon successful authentication and persists after cancelled or failed attempts.

An authorization bypass allows an authenticated attacker to overwrite and confirm another user's email address to take over their account. This occurs because a confirmation token issued to one user is accepted on any other user's record. Specifically, the `AshAuthentication.AddOn.Confirmation.ConfirmChange` function verifies the token's signature and its `act` claim but fails to compare the `sub` claim against `changeset.data` before applying changes to the target record. An attacker can register an account, change their own email, and replay the resulting token against a victim's record ID using `force change attributes/2` to set their own address and stamp `confirmed at`, subsequently gaining access via a password reset. The confirmation flow using `AshAuthentication.AddOn.Confirmation.Actions.confirm/3` is not affected as it correctly resolves `sub` to a user.

AshAuthentication allows the disclosure of user password digests to readers of the audit store. The `audit log` add-on builds `extra data` for each entry in the `AshAuthentication.AddOn.AuditLog.Auditor.build extra data/4` function, which takes the `:actor` from the action callback context verbatim. When an audited action is invoked with `actor:` set to a user record, the record—including the `hashed password` attribute—is deposited into the audit entry. While other identities are collapsed via `AshAuthentication.user to subject/1` and parameters are filtered, the actor remains unfiltered. Setting the attribute `sensitive?: true` is ineffective as it only redacts `inspect/1` output and not JSON encoding or raw-term storage. Exploitation requires independent read access to the audit store (e.g., database credentials, backups, or log shippers), enabling offline password attacks against active accounts. Persistence of this data depends on the data layer; raw-term stores keep it verbatim, whereas SQL stores may drop the entry unless the user resource derives `Jason.Encoder`.

AshAuthentication contains an issue where readers of the audit store can recover client IP addresses that the audit log add-on's `:hash` privacy mode is intended to pseudonymise. The function `hash ip/1` computes an unkeyed `:crypto.hash(:sha256, salt <> ip)` and truncates the result to 16 hexadecimal characters. The salt is retrieved from the `:audit log ip salt` or `:secret` application config keys; however, it defaults to a constant string "default-salt-change-in-production" if neither is set, without providing a warning. Because the IPv4 address space is limited to 2^32 values and SHA-256 is computationally efficient, the hash table can be precomputed, allowing stored values to be mapped back to their original source addresses. This risk persists even with a configured salt if the salt is leaked, as the hash remains cheap to enumerate.

An inefficient algorithmic complexity issue allows an unauthenticated attacker to cause CPU and memory exhaustion by submitting an API key with an oversized base62 segment. The function `AshAuthentication.Base.decode62/1` in `lib/ash authentication/base.ex` processes arguments by splitting them into binaries per character and using `charval62/2`, which recomputes `Integer.pow(62, index)` at every position. This results in a cubic growth in cost relative to input length. Additionally, the `bindecode62/1` function exhibits quadratic growth due to the use of `Integer.undigits/2` and `Integer.digits/2`. Because `AshAuthentication.Strategy.ApiKey.SignInPreparation` processes underscore-separated segments of the submitted key without capping `byte size/1` or requiring prior authentication, the system is susceptible to resource exhaustion that cannot be mitigated by existing rescue clauses.

A Time-of-check Time-of-use (TOCTOU) Race Condition occurs when a magic link is configured with `single use token?`. This allows an attacker with a leaked magic link to replay a single-use token and authenticate as the target subject. The issue arises because the token validity check is not serialized against its consumption, allowing concurrent redemptions to succeed and yield full user tokens. The sign-in process verifies the JWT using `Jwt.verify/4` and revokes it subsequently via `AshAuthentication.Strategy.MagicLink.SignInPreparation` in a `Query.after action` callback and `AshAuthentication.Strategy.MagicLink.SignInChange` in an `after transaction` hook. Because `AshAuthentication.TokenResource.Actions.revoke/3` performs the revocation as an upsert, concurrent duplicate revocations succeed without conflict.

An authentication bypass allows unconfirmed users to obtain a session, bypassing mandatory email confirmation requirements. The issue occurs in the `check user/2` function within `AshAuthentication.Strategy.Password.Actions`, which uses `is nil(Map.get(user, value))` to verify the attribute specified by `require confirmed with`. If the attribute is not selected or denied by a field policy, `Map.get/2` returns `%Ash.NotLoaded{}` or `%Ash.ForbiddenField{}` instead of `nil`, causing the system to incorrectly treat the user as confirmed. Additionally, the `require confirmed with` check is only performed within `AshAuthentication.Strategy.Password.Actions` and not on the actions themselves. Consequently, callers that invoke actions directly, such as `AshGraphql` or `AshJsonApi`, skip the confirmation check entirely in default configurations.

An unauthenticated attacker can forge application log entries by submitting a password reset identity containing newlines or control characters. The function `AshAuthentication.Strategy.Password.RequestPasswordReset.run/3` interpolates the `identity` variable, which contains the email or username from the reset request, into `Logger.warning/1` heredocs without escaping, truncating, or type-restricting it. Because a newline in the `identity` variable ends the log record, any subsequent text is written as a new line, allowing an attacker to manipulate the severity tag and the content of entries to make them appear as if they originated from the application.

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

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.

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.

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.