Private action arguments can be set by user input in Ash
Summary
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 that is intended to be controlled only by trusted server-side code.
Action arguments declared with public?: false are meant to be set internally (for example via Ash.Changeset.set\_private\_argument/3) and must not be settable from end-user input. When a changeset is built from a parameter map, Ash filters out private arguments, but the filtering is incomplete.
In the regular changeset path (for\_create, for\_update, for\_destroy), private arguments are stripped only when the parameter key is an atom. When the key is a binary (string), as is the case for user-supplied parameters, the private argument is kept and the user controls its value. In the atomic path (Ash.Changeset.fully\_atomic\_changeset/4, also reached through atomic and bulk updates), private arguments are not stripped at all, regardless of whether the key is an atom or a binary.
An attacker who can submit parameters to an action that defines a private argument can therefore inject a value for that argument. Depending on how the application uses the argument (for example an acting\_user\_id driving authorization or record ownership), this can lead to an integrity violation or privilege escalation.
This issue affects ash: from 3.0.0 before 3.29.3.
Configuration
An action must declare a private argument (one defined with public?: false) whose value is meant to be set only by trusted server-side code, and the application must build the changeset from untrusted user-supplied parameters, passing them straight into Ash.Changeset.for\_create/3, for\_update/3, for\_destroy/3, or into an atomic or bulk update.
