Uncontrolled Resource Consumption vulnerability in ash-project ash allows an attacker to exhaust the memory of the node via a crafted keyset pagination cursor.

Read actions with keyset pagination deserialize the client-supplied page[:after] or page[:before] cursor in decodevalues/2 in lib/ash/page/keyset.ex, which base64-decodes the value and passes it to :erlang.binarytoterm/2 without bounding its size. The Erlang external term format supports zlib-compressed payloads, which the decoder inflates transparently, so a cursor of a few kilobytes can allocate tens of megabytes of heap in a single call. Ash itself only ever encodes cursors uncompressed, so the decoder accepts a term shape its encoder never produces. Concurrent requests aggregate these allocations and can terminate the node.

This issue affects ash: from 1.17.0 before 3.31.1.

Deserialization of Untrusted Data vulnerability in ash-project ash allows an unauthenticated attacker to inject a filter expression through a forged keyset pagination cursor, resulting in SQL injection or code execution depending on the data layer.

Read actions with keyset pagination decode the client-supplied page[:after] or page[:before] cursor in decodevalues/2 in lib/ash/page/keyset.ex using nonexecutablebinarytoterm/2 with [:safe]. That guard blocks new atoms, funs, and ports, but not a struct built from atoms already interned in a running Ash application, so a decoded %Ash.Query.Call{} expression survives and is spliced into the keyset filter as a comparison value in dofilters/4 and evaluated. Because the cursor bypasses the Ash.Expr macro, the runtime never applies the private?/public? gate that would otherwise reject it. On AshPostgres the injected fragment is inlined into the SQL query; on the ETS and Simple data layers it is evaluated in-process as an arbitrary function call.

This issue affects ash: from 1.17.0 before 3.31.3.

Summary

Ash.Type.Module.castinput/2 unconditionally creates a new Erlang atom via Module.concat([value]) for any user-supplied binary string that starts with "Elixir.", before verifying whether the referenced module exists. Because Erlang atoms are never garbage-collected and the BEAM atom table has a hard default limit of approximately 1,048,576 entries, an attacker who can submit values to any resource attribute or argument of type :module can exhaust this table and crash the entire BEAM VM, taking down the application.

Details

Setup: A resource with a :module-typed attribute exposed to user input, which is a supported and documented usage of the Ash.Type.Module built-in type:

elixir defmodule MyApp.Widget do use Ash.Resource, domain: MyApp, datalayer: AshPostgres.DataLayer

attributes do uuidprimarykey :id attribute :handlermodule, :module, public?: true end

actions do defaults [:read, :destroy] create :create do accept [:handlermodule] end end end

Vulnerable code in lib/ash/type/module.ex, lines 105-113:

elixir def castinput("Elixir." <> = value, ) do module = Module.concat([value]) # <-- Creates new atom unconditionally if Code.ensureloaded?(module) do {:ok, module} else :error # <-- Returns error but atom is already created end end

Exploit: Submit repeated Ash.create requests (e.g., via a JSON API endpoint) with unique "Elixir." strings:

elixir Attacker-controlled loop (or HTTP requests to an API endpoint) for i <- 1..1100000 do Ash.Changeset.forcreate(MyApp.Widget, :create, %{handlermodule: "Elixir.Attack#{i}"}) |> Ash.create() # Each iteration: Module.concat(["Elixir.Attack#{i}"]) creates a new atom # castinput returns :error but the atom :"Elixir.Attack#{i}" persists end After ~1,048,576 unique strings: BEAM crashes with systemlimit

Contrast: The non-"Elixir." path in the same function correctly uses String.toexistingatom/1, which is safe because it only looks up atoms that already exist:

elixir def castinput(value, ) when isbinary(value) do atom = String.toexistingatom(value) # safe - raises if atom doesn't exist ... end

Additional occurrence: caststored/2 at line 141 contains the identical pattern, which is reachable when reading :module-typed values from the database if an attacker can write arbitrary "Elixir." strings to the relevant database column.

Impact

An attacker who can submit requests to any API endpoint backed by an Ash resource with a :module-typed attribute or argument can crash the entire BEAM VM process. This is a complete denial of service: all resources served by that VM instance (not just the targeted resource) become unavailable. The crash cannot be prevented once the atom table is full, and recovery requires a full process restart.

Fix direction: Replace Module.concat([value]) with String.toexistingatom(value) wrapped in a rescue ArgumentError block (as already done in the non-"Elixir." branch), or validate that the atom already exists before calling Module.concat by first attempting String.toexistingatom and only falling back to Module.concat on success.