GHSA-f4hc-ppw9-4hhw: Erlang/ash vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
erlang/ashto a version that resolves this vulnerability.Fixed in 3.29.3 - Compensating control
Do not accept private action arguments declared with `public?: false` from external parameter maps; strip keys such as `acting_user_id` before invoking actions and populate them only with trusted server-side code via `Ash.Changeset.set_private_argument/3`.
Event History
Frequently Asked Questions
Are atom-keyed parameter maps handled differently from string-keyed maps on regular action builders?
Yes. In the regular for_create, for_update, and for_destroy path, atom-keyed arguments are filtered based on public visibility, while binary/string-keyed arguments matching a private argument name can be accepted into changeset.arguments.
Which actions should be prioritized for review?
Prioritize actions that define arguments with public?: false and can be invoked using caller-controlled parameter maps. Externally supplied parameter maps are string-keyed, which is the affected key type identified for the regular action path.