Zach Daniel

Improper neutralization of escape, meta, or control sequences allows a malicious package publisher or a hostile repository server to inject terminal control sequences into the output of Mix tasks. The software prints strings from the package repository and documentation search service directly to the terminal via `Hex.Shell.info/1` and `Hex.Shell.error/1` without neutralizing control characters. This affects package metadata, configuration snippets in `mix hex.info`, search results in `mix hex.package search` and `mix hex.search`, owner and organization listings, publish and sponsor URLs, the authenticated username in `mix hex.user`, policy identities in `mix hex.policy`, and API error bodies rendered by `Hex.Utils.print error result/1`. An attacker can embed ANSI escape sequences—such as cursor movement, line erase, carriage returns, and OSC 52 clipboard writes—or Unicode bidirectional overrides to forge displayed URLs, package descriptions, and suggested commands, conceal real output, or write to the clipboard. This can be triggered by any developer running a documentation search that surfaces a malicious package.

An unauthenticated attacker can inject a filter expression using a forged keyset pagination cursor. This occurs because read actions with keyset pagination decode client-supplied `page[:after]` or `page[:before]` cursors in the `decode values/2` function within `lib/ash/page/keyset.ex` using `non executable binary to term/2` with `[:safe]`. While this guard blocks new atoms, funs, and ports, it does not block structs built from atoms already interned in a running application. Consequently, a decoded `%Ash.Query.Call{}` expression can be spliced into the keyset filter as a comparison value in `do filters/4` and evaluated. Since the cursor bypasses the `Ash.Expr` macro, the runtime fails to apply the `private?/public?` gate. The impact varies by data layer: AshPostgres allows SQL injection, while ETS and Simple data layers allow the expression to be evaluated in-process as an arbitrary function call.

An uncontrolled resource consumption issue exists where an attacker can exhaust node memory using a crafted keyset pagination cursor. Read actions utilizing keyset pagination deserialize client-supplied cursors via the `decode values/2` function in `lib/ash/page/keyset.ex`. This process base64-decodes the value and passes it to `:erlang.binary to term/2` without size bounding. Because the Erlang external term format supports zlib-compressed payloads, the decoder may inflate a small cursor into tens of megabytes of heap memory. Since the software only encodes cursors as uncompressed, the decoder accepts term shapes that the encoder does not produce. Multiple concurrent requests can aggregate these allocations and cause the node to terminate. This involves the `page[:after]` and `page[:before]` variables.

Improper Neutralization of Special Elements in Data Query Logic allows an attacker to forge a relationship to a record they cannot name and recover the secret value used for lookup. This occurs when `manage relationship` is used with `on lookup: :relate` on a `belongs to` relationship, as the client-supplied lookup value is passed to `Ash.Query.filter/2` without being cast to the attribute type. Consequently, a nested map submitted instead of a scalar is interpreted as a filter predicate rather than a literal, transforming a specific record lookup into a query for any record matching a condition. Additionally, the omission of `Ash.Query.limit(1)` allows `Ash.read one/2` to distinguish between no match, one match, and several matches, creating an oracle for the lookup value. Authorization remains unaffected as the destination read policy still applies.

An issue exists where users can set the value of a private action argument intended to be controlled exclusively by trusted server-side code. Action arguments declared with `public?: false` are meant for internal settings, such as those via `Ash.Changeset.set private argument/3`, and should not be settable via end-user input. However, filtering of these private arguments is incomplete when a changeset is built from a parameter map. In regular changeset paths (`for create`, `for update`, `for destroy`), private arguments are only stripped if the parameter key is an atom; if the key is a binary (string), which is common for user-supplied parameters, the argument is retained. In the atomic path (`Ash.Changeset.fully atomic changeset/4`, including atomic and bulk updates), private arguments are not stripped regardless of the key type. This allows an attacker to inject values into private arguments, potentially leading to privilege escalation or integrity violations, especially if arguments like `acting user id` are used for authorization or record ownership.

An incorrect authorization issue exists in ash, potentially allowing authentication bypass. The issue is associated with the `lib/ash/policy/policy.ex` file and the `Elixir.Ash.Policy.Policy`:expression/2 function.

An incorrect authorization issue exists in ash-project ash, allowing authentication bypass. The issue is associated with the program files `lib/ash/policy/authorizer/authorizer.ex` and the `Elixir.Ash.Policy.Authorizer`:strict filters/2 routine.

An incorrect authorization vulnerability exists in ash, allowing exploitation of incorrectly configured access control security levels. This issue is associated with program files `lib/ash/actions/create/bulk.ex`, `lib/ash/actions/destroy/bulk.ex`, `lib/ash/actions/update/bulk.ex`, and program routines `Elixir.Ash.Actions.Create.Bulk`:run/5, `Elixir.Ash.Actions.Destroy.Bulk`:run/6, and `Elixir.Ash.Actions.Update.Bulk:run`/6.

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.