Ash Authentication
Monthly
Authentication bypass in the Elixir library ash_authentication lets an attacker who operates one federated identity-provider connection of a `dynamic_oidc` strategy be signed in as a local user whose identity row was created through a different IdP connection, because the intended per-connection namespacing of the `strategy` field never persists. Affected are versions 5.0.0-rc.10 through 5.0.0-rc.13 (fixed in 5.0.0-rc.14); the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, so the flaw is network-reachable and unauthenticated in the token-presentation sense, but real-world exploitation is tightly gated: the deployment must use `dynamic_oidc` with more than one identity-provider connection, the attacker must control (or have a trusted operator position on) one of those connections, and must be able to mint tokens with a chosen `sub` claim that collides with a target subject. No public exploit code was identified at time of analysis, and this CVE is not listed in CISA KEV; patch commits are already public, so the exposure window for unpatched, multi-connection deployments is the operational concern.
Account takeover in AshAuthentication (Elixir/Ash) 4.14.0 through 4.14.x and 5.0.0-rc.10 through 5.0.0-rc.13 lets unauthenticated remote attackers obtain a session for another user's account by linking their own OAuth2 provider identity to an account that was matched on an attribute other than email, and the same upsert rewrites the victim's email to the attacker's address so subsequent account recovery flows reach the attacker. Exploitation is conditional: the application must configure the OAuth2/Auth0/Apple strategy with a register-action upsert_identity that matches existing accounts on a non-email attribute, or use the registration_enabled? false sign-in path where accounts are matched by the sign-in action's read filter, and the attacker only needs control of a provider identity whose email_verified claim is true. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV); vendor patches are available in 4.15.0 and 5.0.0-rc.14.
Unconfirmed accounts can obtain an authenticated session in the AshAuthentication Elixir library, defeating the mandatory email-confirmation gate configured through the password strategy's require_confirmed_with option. The check in AshAuthentication.Strategy.Password.Actions.check_user/2 compares the confirmation attribute against nil with a bare is_nil(Map.get(user, field)), so Ash's %Ash.NotLoaded{} and %Ash.ForbiddenField{} sentinels - returned when the attribute is not selected on the loaded record or is hidden from the current actor by a field policy - are treated as a confirmed value; the check also exists only inside the strategy's Actions module and is not attached to the sign-in/register action itself, so callers that invoke the action directly, including API layers such as AshGraphql and AshJsonApi in the default configuration, skip it entirely. Unauthenticated per the CVSS 4.0 vector (PR:N, with AT:P indicating the target must actually have require_confirmed_with configured), CVSS 9.1, CWE-305 (Authentication Bypass by Primary Weakness); no public exploit identified at time of analysis, and vendor patches are available in 4.15.0 and 5.0.0-rc.14.
Revoked sessions continue to be treated as fully authenticated on affected AshAuthentication and AshAuthentication Phoenix deployments, so anyone holding a session value captured before the victim signed out can keep acting as that user indefinitely. The flaw affects ash_authentication_phoenix from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 onward, and ash_authentication from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14, but only for resources configured with session_identifier :jti while require_token_presence_for_authentication? is disabled; deployments using require_token_presence_for_authentication? true validate the token and are not affected. No public exploit identified at time of analysis, though the upstream advisory rates the issue 9.1 and vendor patches are already published.
Password sign-in in AshAuthentication Phoenix (ash_authentication_phoenix 1.7.0 to <2.17.4 and 3.0.0-rc.0 to <3.0.0-rc.11, with the companion ash_authentication 3.10.5 to <4.15.0 and 5.0.0-rc.0 to <5.0.0-rc.14) places a freshly issued single-use sign-in token in the query string of a GET redirect to the sign_in_with_token route, so the live credential is written into the request line where it is retained by web server access logs, reverse-proxy logs, request telemetry and the victim's browser history. Anyone who can read those artifacts - and can replay the token before the legitimate redirect consumes it or it expires - can authenticate as the affected user. The exposure is only reachable when sign_in_tokens_enabled? is true and the password sign-in form is in use; the vendor rates it CVSS 4.0 7.2 (AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H) and our independent assessment aligns at CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, indicating no public exploit identified at time of analysis rather than remotely exploitable default-configuration compromise.
Authentication bypass in the AshAuthentication library for Elixir/Ash lets an authenticated attacker who holds a valid sign-in token minted for one Ash resource replay it to be signed in as a user of a different resource, because the JWT 'sub' claim's path segment - the only portion recording which subject the token was issued for - is parsed with URI.parse/1 and thrown away, leaving only the query string. Affected are ash_authentication releases from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14, specifically the Password sign-in-with-token, WebAuthn sign-in and remember-me preparations; the magic-link sign-in path pins the subject against the resource and is not vulnerable. Exploitation is configuration-dependent - it requires two or more authenticated resources whose primary-key field names are identical (for example, both 'id') - and no public exploit code was identified at time of analysis.
Reusing a leaked single-use magic-link token is possible in the Elixir library ash_authentication because its validity check and its revocation are not serialised: concurrent sign-in redemptions of the same token can all succeed, each returning a full user JWT and authenticating the attacker as the target subject. Affected are ash_authentication versions from 3.9.0 before 4.15.0 and 5.0.0-rc.0 before 5.0.0-rc.14, with single_use_token? enabled (the default) - unauthenticated remote requests (PR:N) qualify, but the attacker must already possess a valid, unexpired magic link obtained out-of-band and must win a non-deterministic timing race, so real-world risk is materially lower than the headline CVSS 4.0 score of 9.1 suggests. There is no indication of confirmed active exploitation (no CISA KEV entry) and no public exploit identified at time of analysis; vendor patches are available.
An authenticated account-takeover primitive exists in the Elixir library AshAuthentication (ash_authentication) versions 0.5.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13: an attacker who can register their own account can replay the confirmation token generated for their own email change against a victim's record, causing the victim's address to be overwritten with the attacker's and confirmed_at to be stamped, after which a routine password reset hands over the account. Exploitation requires the application to use the Confirmation add-on with monitored fields (typically :email), the attacker's own registered account (authenticated, PR:L), and knowledge of the victim's record id (normally a UUID primary key); no action by the victim is required. The confirmation flow the library itself generates is not affected, and no public exploit code has been identified at time of analysis.
Denial of service in the AshAuthentication API-key sign-in strategy lets an unauthenticated, remote attacker exhaust server CPU and memory by submitting an API key containing an oversized base62 segment. Affected are ash_authentication releases from 4.8.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14 that enable the ApiKey strategy; the malicious input is decoded before any key lookup, so no credentials, valid key, or user interaction is required (CVSS 4.0 base 8.2; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/A:H). No public exploit code or active exploitation was identified at time of analysis, and vendor fixes are available in 4.15.0 and 5.0.0-rc.14.
JWT token replay in AshAuthentication exposes any application using the stateless bearer-token path to full account takeover using purpose-scoped tokens. The `retrieve_from_bearer/3` helper in versions 3.10.5-4.14.2 and 5.0.0-rc.0-5.0.0-rc.13 verifies JWT signatures and rejects tokens with an `act` claim, but never validates that the token's `purpose` claim equals "user", allowing sign-in, remember-me, and TOTP-setup tokens to be silently accepted as full bearer credentials. No public exploit has been identified at time of analysis, but the attack requires only obtaining a still-valid, not-yet-exchanged sign-in token - a realistic threat surface via log leakage, referrer exposure, or intercepted magic-link delivery.
Account takeover in team-alembic AshAuthentication (0.1.0 to <4.14.0 and 5.0.0-rc.0 to <5.0.0-rc.10) lets an unauthenticated attacker hijack any local user account by completing an OAuth2 or OIDC sign-in with the victim's email address. The library matched federated logins to local users by email rather than by the OpenID Connect iss/sub pair, so any accepted provider that allows an attacker to register or reuse the victim's email - including providers that return email_verified: false - resolves to the victim's existing account. No public exploit identified at time of analysis, but the underlying technique (OIDC email-claim takeover) is well-documented and trivially reproducible.
AshAuthentication's token-revocation action accepts forged JWTs without verifying their signature, letting an unauthenticated remote caller write arbitrary rows into the token resource or neutralise an existing revocation. Because the revocation record's expires_at is derived from the attacker-supplied exp claim, an attacker holding a copy of a genuine token can resubmit it with the real jti intact but a backdated exp, producing a revocation row that is already expired; once expunge_expired prunes it, the genuine token validates again through revoked? and logout-based invalidation is defeated. The weakness is confined to token-revocation state in ash_authentication 0.2.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13 (CVSS 6.9 per the CVSS 4.0 vector; an independent assessment scores it CVSS 3.1 5.3 with integrity-only impact and no confidentiality or availability loss), and no public exploit identified at time of analysis.
Log forgery in the AshAuthentication Elixir library allows any remote attacker who can reach an application's password-reset request action to inject arbitrary, attacker-controlled lines into the application's logs, including forged severity tags and messages that appear to originate from the application itself. Affected versions are ash_authentication 4.2.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13; the flaw is CWE-117 (improper output neutralization for logs) and is rated 6.3 under CVSS v4.0, with the independent assessment settling on CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - an integrity-only, low-impact issue rather than a high-priority emergency. Impact is confined to misleading or forged log records (no confidentiality or availability effect) and materializes only where logs are retained, reviewed, or fed into a SIEM/log-processing pipeline, which is the 'attack requirement beyond the attacker's control' reflected in the AT:P vector component; no public exploit has been identified at time of analysis, though the upstream fix commits are public.
OAuth2 login CSRF affects AshAuthentication, the authentication extension for the Ash framework in Elixir: the OAuth2 callback plug fails to delete the stored session_params value when an authorization attempt fails or is cancelled, so an attacker who learns that value can replay the callback and sign a victim into an attacker-controlled account. The flaw is reachable in ash_authentication 0.6.0 up to (but not including) 4.15.0, and in the 5.0.0-rc.0 through 5.0.0-rc.13 pre-releases, and requires the victim to be induced to replay the callback within the same session before the next request phase or session expiry consumes the value - unauthenticated but dependent on user interaction, per the assessed vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R. Exploitation yields limited confidentiality and integrity impact (login CSRF onto an attacker's account rather than takeover of the victim's account), EPSS and KEV data were not provided, and no public exploit identified at time of analysis; vendor patches are available.
The audit-log add-on in AshAuthentication stores pseudonymised client IP addresses using an unkeyed SHA-256 over a salt concatenated with the IP, truncated to 16 hex characters, so anyone who can already read the audit store can reverse those values back to the original addresses. Exploitation requires two explicit prerequisites: ip_privacy_mode must be set to :hash (the DSL default is :none, so this is an opt-in), and the attacker must already hold read access to the audit log via a database dump, backup, replica, or reader account. Reversal is trivial when the salt is left at the library's published fallback constant 'default-salt-change-in-production', which is used silently with no warning; even a properly configured salt only reduces the problem to 'that salt must leak', after which exhaustive enumeration over the 2^32 IPv4 space is cheap. Per the authoritative assessment this is a low-priority information-disclosure issue (assessed CVSS 3.1 1.8, CWE-760) affecting only client IP addresses with no integrity or availability impact; no public exploit identified at time of analysis, and vendor-released patches exist in 4.15.0 and 5.0.0-rc.14.
The audit_log add-on in the Elixir library AshAuthentication (ash_authentication) writes the full actor record into each audit entry's extra_data field, so the user's hashed_password digest is stored alongside the audit trail in versions from 4.12.0 up to but not including 4.15.0, and from 5.0.0-rc.0 up to but not including 5.0.0-rc.2. There is no network-facing or attacker-triggered disclosure path: entries accumulate from ordinary authenticated activity controlled by benign code, and an attacker's own requests only deposit the attacker's own digest, so exploitation requires that the attacker already hold independent read access to the audit store (database credentials, an audit role, a backup, or a log shipper). The result is exposure of password hashes that support offline cracking of every active account whose actions were audited; the vector is local, high complexity, and privileged (per the assessment PR:H), making this a log-hygiene/defense-in-depth issue rather than an actively exploited one - no public exploit code or CISA KEV entry has been identified at time of analysis, and vendor patches are available.
Reflected XSS in AshAuthentication's confirmation and magic link interaction pages allows unauthenticated attackers to inject arbitrary JavaScript into a victim's browser by crafting a malicious GET URL. Versions 4.8.0 through 4.14.1 and 5.0.0-rc.0 through 5.0.0-rc.12 of this Elixir framework authentication library embed user-supplied request parameters verbatim into hidden HTML form inputs using unescaped EEx template expressions, and since the vulnerable accept handlers are served over GET, simply loading the crafted link is sufficient - no form submission or prior session is required. No public exploit code has been independently identified at time of analysis, though the attack is trivially constructable from the public advisory and commit diff alone.
Ash Authentication is an authentication framework for Elixir applications. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.
Authentication bypass in the Elixir library ash_authentication lets an attacker who operates one federated identity-provider connection of a `dynamic_oidc` strategy be signed in as a local user whose identity row was created through a different IdP connection, because the intended per-connection namespacing of the `strategy` field never persists. Affected are versions 5.0.0-rc.10 through 5.0.0-rc.13 (fixed in 5.0.0-rc.14); the assessed vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, so the flaw is network-reachable and unauthenticated in the token-presentation sense, but real-world exploitation is tightly gated: the deployment must use `dynamic_oidc` with more than one identity-provider connection, the attacker must control (or have a trusted operator position on) one of those connections, and must be able to mint tokens with a chosen `sub` claim that collides with a target subject. No public exploit code was identified at time of analysis, and this CVE is not listed in CISA KEV; patch commits are already public, so the exposure window for unpatched, multi-connection deployments is the operational concern.
Account takeover in AshAuthentication (Elixir/Ash) 4.14.0 through 4.14.x and 5.0.0-rc.10 through 5.0.0-rc.13 lets unauthenticated remote attackers obtain a session for another user's account by linking their own OAuth2 provider identity to an account that was matched on an attribute other than email, and the same upsert rewrites the victim's email to the attacker's address so subsequent account recovery flows reach the attacker. Exploitation is conditional: the application must configure the OAuth2/Auth0/Apple strategy with a register-action upsert_identity that matches existing accounts on a non-email attribute, or use the registration_enabled? false sign-in path where accounts are matched by the sign-in action's read filter, and the attacker only needs control of a provider identity whose email_verified claim is true. No public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV); vendor patches are available in 4.15.0 and 5.0.0-rc.14.
Unconfirmed accounts can obtain an authenticated session in the AshAuthentication Elixir library, defeating the mandatory email-confirmation gate configured through the password strategy's require_confirmed_with option. The check in AshAuthentication.Strategy.Password.Actions.check_user/2 compares the confirmation attribute against nil with a bare is_nil(Map.get(user, field)), so Ash's %Ash.NotLoaded{} and %Ash.ForbiddenField{} sentinels - returned when the attribute is not selected on the loaded record or is hidden from the current actor by a field policy - are treated as a confirmed value; the check also exists only inside the strategy's Actions module and is not attached to the sign-in/register action itself, so callers that invoke the action directly, including API layers such as AshGraphql and AshJsonApi in the default configuration, skip it entirely. Unauthenticated per the CVSS 4.0 vector (PR:N, with AT:P indicating the target must actually have require_confirmed_with configured), CVSS 9.1, CWE-305 (Authentication Bypass by Primary Weakness); no public exploit identified at time of analysis, and vendor patches are available in 4.15.0 and 5.0.0-rc.14.
Revoked sessions continue to be treated as fully authenticated on affected AshAuthentication and AshAuthentication Phoenix deployments, so anyone holding a session value captured before the victim signed out can keep acting as that user indefinitely. The flaw affects ash_authentication_phoenix from 2.10.0 before 2.17.4 and from 3.0.0-rc.0 onward, and ash_authentication from 4.9.1 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14, but only for resources configured with session_identifier :jti while require_token_presence_for_authentication? is disabled; deployments using require_token_presence_for_authentication? true validate the token and are not affected. No public exploit identified at time of analysis, though the upstream advisory rates the issue 9.1 and vendor patches are already published.
Password sign-in in AshAuthentication Phoenix (ash_authentication_phoenix 1.7.0 to <2.17.4 and 3.0.0-rc.0 to <3.0.0-rc.11, with the companion ash_authentication 3.10.5 to <4.15.0 and 5.0.0-rc.0 to <5.0.0-rc.14) places a freshly issued single-use sign-in token in the query string of a GET redirect to the sign_in_with_token route, so the live credential is written into the request line where it is retained by web server access logs, reverse-proxy logs, request telemetry and the victim's browser history. Anyone who can read those artifacts - and can replay the token before the legitimate redirect consumes it or it expires - can authenticate as the affected user. The exposure is only reachable when sign_in_tokens_enabled? is true and the password sign-in form is in use; the vendor rates it CVSS 4.0 7.2 (AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H) and our independent assessment aligns at CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, indicating no public exploit identified at time of analysis rather than remotely exploitable default-configuration compromise.
Authentication bypass in the AshAuthentication library for Elixir/Ash lets an authenticated attacker who holds a valid sign-in token minted for one Ash resource replay it to be signed in as a user of a different resource, because the JWT 'sub' claim's path segment - the only portion recording which subject the token was issued for - is parsed with URI.parse/1 and thrown away, leaving only the query string. Affected are ash_authentication releases from 3.10.5 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14, specifically the Password sign-in-with-token, WebAuthn sign-in and remember-me preparations; the magic-link sign-in path pins the subject against the resource and is not vulnerable. Exploitation is configuration-dependent - it requires two or more authenticated resources whose primary-key field names are identical (for example, both 'id') - and no public exploit code was identified at time of analysis.
Reusing a leaked single-use magic-link token is possible in the Elixir library ash_authentication because its validity check and its revocation are not serialised: concurrent sign-in redemptions of the same token can all succeed, each returning a full user JWT and authenticating the attacker as the target subject. Affected are ash_authentication versions from 3.9.0 before 4.15.0 and 5.0.0-rc.0 before 5.0.0-rc.14, with single_use_token? enabled (the default) - unauthenticated remote requests (PR:N) qualify, but the attacker must already possess a valid, unexpired magic link obtained out-of-band and must win a non-deterministic timing race, so real-world risk is materially lower than the headline CVSS 4.0 score of 9.1 suggests. There is no indication of confirmed active exploitation (no CISA KEV entry) and no public exploit identified at time of analysis; vendor patches are available.
An authenticated account-takeover primitive exists in the Elixir library AshAuthentication (ash_authentication) versions 0.5.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13: an attacker who can register their own account can replay the confirmation token generated for their own email change against a victim's record, causing the victim's address to be overwritten with the attacker's and confirmed_at to be stamped, after which a routine password reset hands over the account. Exploitation requires the application to use the Confirmation add-on with monitored fields (typically :email), the attacker's own registered account (authenticated, PR:L), and knowledge of the victim's record id (normally a UUID primary key); no action by the victim is required. The confirmation flow the library itself generates is not affected, and no public exploit code has been identified at time of analysis.
Denial of service in the AshAuthentication API-key sign-in strategy lets an unauthenticated, remote attacker exhaust server CPU and memory by submitting an API key containing an oversized base62 segment. Affected are ash_authentication releases from 4.8.0 before 4.15.0 and from 5.0.0-rc.0 before 5.0.0-rc.14 that enable the ApiKey strategy; the malicious input is decoded before any key lookup, so no credentials, valid key, or user interaction is required (CVSS 4.0 base 8.2; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/A:H). No public exploit code or active exploitation was identified at time of analysis, and vendor fixes are available in 4.15.0 and 5.0.0-rc.14.
JWT token replay in AshAuthentication exposes any application using the stateless bearer-token path to full account takeover using purpose-scoped tokens. The `retrieve_from_bearer/3` helper in versions 3.10.5-4.14.2 and 5.0.0-rc.0-5.0.0-rc.13 verifies JWT signatures and rejects tokens with an `act` claim, but never validates that the token's `purpose` claim equals "user", allowing sign-in, remember-me, and TOTP-setup tokens to be silently accepted as full bearer credentials. No public exploit has been identified at time of analysis, but the attack requires only obtaining a still-valid, not-yet-exchanged sign-in token - a realistic threat surface via log leakage, referrer exposure, or intercepted magic-link delivery.
Account takeover in team-alembic AshAuthentication (0.1.0 to <4.14.0 and 5.0.0-rc.0 to <5.0.0-rc.10) lets an unauthenticated attacker hijack any local user account by completing an OAuth2 or OIDC sign-in with the victim's email address. The library matched federated logins to local users by email rather than by the OpenID Connect iss/sub pair, so any accepted provider that allows an attacker to register or reuse the victim's email - including providers that return email_verified: false - resolves to the victim's existing account. No public exploit identified at time of analysis, but the underlying technique (OIDC email-claim takeover) is well-documented and trivially reproducible.
AshAuthentication's token-revocation action accepts forged JWTs without verifying their signature, letting an unauthenticated remote caller write arbitrary rows into the token resource or neutralise an existing revocation. Because the revocation record's expires_at is derived from the attacker-supplied exp claim, an attacker holding a copy of a genuine token can resubmit it with the real jti intact but a backdated exp, producing a revocation row that is already expired; once expunge_expired prunes it, the genuine token validates again through revoked? and logout-based invalidation is defeated. The weakness is confined to token-revocation state in ash_authentication 0.2.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13 (CVSS 6.9 per the CVSS 4.0 vector; an independent assessment scores it CVSS 3.1 5.3 with integrity-only impact and no confidentiality or availability loss), and no public exploit identified at time of analysis.
Log forgery in the AshAuthentication Elixir library allows any remote attacker who can reach an application's password-reset request action to inject arbitrary, attacker-controlled lines into the application's logs, including forged severity tags and messages that appear to originate from the application itself. Affected versions are ash_authentication 4.2.0 through 4.14.x and 5.0.0-rc.0 through 5.0.0-rc.13; the flaw is CWE-117 (improper output neutralization for logs) and is rated 6.3 under CVSS v4.0, with the independent assessment settling on CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - an integrity-only, low-impact issue rather than a high-priority emergency. Impact is confined to misleading or forged log records (no confidentiality or availability effect) and materializes only where logs are retained, reviewed, or fed into a SIEM/log-processing pipeline, which is the 'attack requirement beyond the attacker's control' reflected in the AT:P vector component; no public exploit has been identified at time of analysis, though the upstream fix commits are public.
OAuth2 login CSRF affects AshAuthentication, the authentication extension for the Ash framework in Elixir: the OAuth2 callback plug fails to delete the stored session_params value when an authorization attempt fails or is cancelled, so an attacker who learns that value can replay the callback and sign a victim into an attacker-controlled account. The flaw is reachable in ash_authentication 0.6.0 up to (but not including) 4.15.0, and in the 5.0.0-rc.0 through 5.0.0-rc.13 pre-releases, and requires the victim to be induced to replay the callback within the same session before the next request phase or session expiry consumes the value - unauthenticated but dependent on user interaction, per the assessed vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R. Exploitation yields limited confidentiality and integrity impact (login CSRF onto an attacker's account rather than takeover of the victim's account), EPSS and KEV data were not provided, and no public exploit identified at time of analysis; vendor patches are available.
The audit-log add-on in AshAuthentication stores pseudonymised client IP addresses using an unkeyed SHA-256 over a salt concatenated with the IP, truncated to 16 hex characters, so anyone who can already read the audit store can reverse those values back to the original addresses. Exploitation requires two explicit prerequisites: ip_privacy_mode must be set to :hash (the DSL default is :none, so this is an opt-in), and the attacker must already hold read access to the audit log via a database dump, backup, replica, or reader account. Reversal is trivial when the salt is left at the library's published fallback constant 'default-salt-change-in-production', which is used silently with no warning; even a properly configured salt only reduces the problem to 'that salt must leak', after which exhaustive enumeration over the 2^32 IPv4 space is cheap. Per the authoritative assessment this is a low-priority information-disclosure issue (assessed CVSS 3.1 1.8, CWE-760) affecting only client IP addresses with no integrity or availability impact; no public exploit identified at time of analysis, and vendor-released patches exist in 4.15.0 and 5.0.0-rc.14.
The audit_log add-on in the Elixir library AshAuthentication (ash_authentication) writes the full actor record into each audit entry's extra_data field, so the user's hashed_password digest is stored alongside the audit trail in versions from 4.12.0 up to but not including 4.15.0, and from 5.0.0-rc.0 up to but not including 5.0.0-rc.2. There is no network-facing or attacker-triggered disclosure path: entries accumulate from ordinary authenticated activity controlled by benign code, and an attacker's own requests only deposit the attacker's own digest, so exploitation requires that the attacker already hold independent read access to the audit store (database credentials, an audit role, a backup, or a log shipper). The result is exposure of password hashes that support offline cracking of every active account whose actions were audited; the vector is local, high complexity, and privileged (per the assessment PR:H), making this a log-hygiene/defense-in-depth issue rather than an actively exploited one - no public exploit code or CISA KEV entry has been identified at time of analysis, and vendor patches are available.
Reflected XSS in AshAuthentication's confirmation and magic link interaction pages allows unauthenticated attackers to inject arbitrary JavaScript into a victim's browser by crafting a malicious GET URL. Versions 4.8.0 through 4.14.1 and 5.0.0-rc.0 through 5.0.0-rc.12 of this Elixir framework authentication library embed user-supplied request parameters verbatim into hidden HTML form inputs using unescaped EEx template expressions, and since the vulnerable accept handlers are served over GET, simply loading the crafted link is sufficient - no form submission or prior session is required. No public exploit code has been independently identified at time of analysis, though the attack is trivially constructable from the public advisory and commit diff alone.
Ash Authentication is an authentication framework for Elixir applications. Rated medium severity (CVSS 6.3), this vulnerability is remotely exploitable, no authentication required. Public exploit code available.