Incorrect Authorization vulnerability in ash-project ash allows a client to read destination records unrelated to the source record through a through relationship.

When a hasmany relationship declared with through: was loaded for a single record with a limit of 1, or an unsorted hasone through relationship was loaded with a limit of 1, lateraljoin?/4 in lib/ash/actions/read/relationships.ex chose the path that reads the destination without any filter linking it to the source. The load returned the first destination record by sort, or any other record with an offset. The read still runs the destination's policies but carries the relationship as accessingfrom, so a client paging such a field (for example teachers(limit: 1, offset: n) through AshGraphql) can enumerate destination records that policies allow only when reached through that relationship.

This issue affects ash: from 3.24.0 before 3.37.1.

Incorrect Authorization vulnerability in ash-project ash allows an actor to infer data in related records they cannot read via Ash.count/2, Ash.exists/2 and Ash.aggregate/3.

Ash.Actions.Aggregate.run/4 (lib/ash/actions/aggregate.ex) applied only the root resource's read policy before running the aggregate query. The read path also applies each related resource's read policy to filter and sort references that cross a relationship, directly (for example comments.body) or through an aggregate over one, but the aggregate path skipped that step. A caller whose filter or sort reaches these functions, for example through Ash.Query.filterinput/2, an ashlua script, or an AshAi tool offering count or exists results, can test conditions against related rows hidden from them and recover their existence and attribute values one query at a time. Ash.read/2 and its page counts are not affected.

This issue affects ash: from 2.6.0 before 3.34.6.

Ash stores :atom-typed attributes as strings and compares them as strings. When such an attribute is referenced in a filter, the comparison value is coerced through Ash.Type.Atom. Because the type defined no coerce/2 callback, coercion fell back to the default (castinput/2), which calls String.toatom/1 when the attribute is configured with the unsafetoatom?: true constraint.

Filtering such an attribute with attacker-controlled strings therefore interned a new, permanent atom for every distinct value. Atoms are never garbage collected and the BEAM caps the atom table, so an actor who can supply filter values for a public, filterable :atom attribute declared with unsafetoatom?: true can exhaust the atom table and crash the node (denial of service). AshPaperTrail is a notable example: its version resources expose a public, filterable versionactionname atom attribute with unsafetoatom?: true by default.

The fix adds a coerce/2 to Ash.Type.Atom that never interns atoms — a comparison value is left as a string, since the type is stored and compared as a string. Setting the attribute from action input (castinput/2, which still honors unsafetoatom?) is unchanged.

This issue affects ash: from 3.5.1 before 3.34.3.

Improperly Controlled Modification of Dynamically-Determined Object Attributes vulnerability in ash-project ash allows a user to set the value of a private action argument on the bulk destroy and bulk update paths.

Action arguments declared with public?: false are meant to be set only by trusted server-side code (for example via Ash.Changeset.setprivateargument/3) and must not be settable from end-user input. CVE-2026-55736 fixed the non-bulk changeset path to strip private arguments from user-supplied parameter maps, but the bulk destroy and bulk update paths were not covered.

Ash.Actions.Destroy.Bulk.basechangeset/5 and Ash.Actions.Update.Bulk.basechangeset/5 match every key in the caller-supplied parameter map against all of the action's arguments with no public? check, then apply the matches to the base changeset. A caller who can submit parameters to a bulk destroy or bulk update action (for example through AshJsonApi, AshGraphql, or a controller that forwards request parameters to Ash.bulkdestroy/4 or Ash.bulkupdate/4) can therefore set any private argument of that action, including one referenced by an arg(...) template in the action's changes or validations. Depending on how the application uses the argument (for example an actinguserid driving authorization or record ownership, or audit metadata), this can lead to an integrity violation or privilege escalation.

The fix requires public? in the argument matching on both bulk paths; private arguments remain settable server-side via the :privatearguments option.

This issue affects ash: from 2.17.15 before 3.33.11.

Summary

Ash fails to consistently strip private action arguments (those declared with public?: false) when a changeset is built from an untrusted parameter map. Private arguments are meant to be set only by trusted server-side code, but a caller who controls the parameters supplied to an action can inject a value for one. Any actor able to submit parameters to an action that defines a private argument can trigger it.

Details

Private arguments (public?: false) are meant to be populated internally (e.g. via Ash.Changeset.setprivateargument/3) and never accepted from external input. When an action is invoked with a parameter map, Ash should discard keys that name a private argument. The filtering in lib/ash/changeset/changeset.ex is incomplete, and the gap differs across the two parameter paths.

1. Regular path (forcreate, forupdate, fordestroy). castparams/4 validates keys via getactionargument/2. Its atom-keyed clause filters on public?, but the binary-keyed (string) clause does not, so a string key matching a private argument name is accepted and written into changeset.arguments. User-supplied parameter maps are string-keyed, making this the reachable case.

2. Atomic / bulk path (Ash.Changeset.fullyatomicchangeset/4). atomicparams/4 gates assignment on hasargument?/2, whose atom and binary clauses both omit the public? check, so private arguments are accepted regardless of key type.

PoC

1. Define an action with a private argument, e.g. argument :actinguserid, :string, public?: false, and a change that writes it into an attribute. 2. Build the changeset from a string-keyed map including it, e.g. Ash.Changeset.forcreate(Resource, :place, %{"item" => "book", "actinguserid" => "victim-user-id"}). 3. Observe actinguserid is present in changeset.arguments and persisted, whereas the same map with atom keys is correctly stripped. 4. For the atomic path, call Ash.Changeset.fullyatomicchangeset(Resource, :promote, %{"actinguserid" => "victim-user-id"}) (atom or string keys) and observe the private argument is retained either way.

Impact

An attacker who can submit parameters to an action that defines a private argument can set that argument to a value of their choosing, overriding data the application intended to control server-side. Where a private argument drives authorization, identity, or record ownership (e.g. actinguserid), this can lead to an integrity violation or privilege escalation.