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.

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.