CVE-2026-67579

Ash Framework (the ash Elixir package) before 3.31.3 fails to safely deserialize the client-supplied keyset pagination cursor (page[:after] or page[:before]) consumed by read actions. The :safe option passed to non_executable_binary_to_term/2 blocks new atoms, functions, and ports, but it does not block structs built from atoms already loaded in a running Ash application, so an attacker can forge a cursor containing an %Ash.Query.Call{} expression that is spliced into the keyset filter without the normal public/private expression gating. On the AshPostgres data layer the injected call is inlined into the SQL query, yielding SQL injection; on the ETS and Simple data layers it is evaluated in-process, yielding arbitrary code execution. Any application running ash 1.17.0 through 3.31.2 that exposes keyset-paginated read actions to untrusted clients is affected, with impact depending on the data layer in use. No confirmed in-the-wild exploitation is reported; a public advisory with a proof of concept (GHSA-3gq3-9xm3-c8v3) is available and EPSS estimates roughly a 0.8% chance of exploitation within 30 days.

What to do: Upgrade to ash 3.31.3 or later, which is the first fixed release. As an interim mitigation, restrict keyset pagination parameters (page[:after]/page[:before]) on read actions to trusted callers and validate cursor input before it reaches the keyset decoder. Prioritize patching where AshPostgres backs unauthenticated read actions (SQL injection risk) or where ETS/Simple data layers are used (code execution risk), and review GHSA-3gq3-9xm3-c8v3 for the published proof of concept.