GHSA-f4hc-ppw9-4hhw: Erlang/ash vulnerability

Published Sep 24, 2026
·
Updated

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

1 affected componentFixes available
erlang/ash>=3.0.0<3.29.3
3.29.3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade erlang/ash to a version that resolves this vulnerability.

    Fixed in 3.29.3
  2. 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

Sep 24, 2026
Advisory Published
via GitHub·07:53 PM
Data Sourced
via GitHub·07:53 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

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.

2

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203