CVE-2026-55736: Private action arguments can be set by user input in Ash

Published Jun 23, 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.

Other sources

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.setprivateargument/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 (forcreate, forupdate, fordestroy), 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.fullyatomicchangeset/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 actinguserid 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.

— NVD

Affected Software

2 affected componentsFixes available
hex/ash>=3.0.0<3.29.3
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. Upgrade

    Upgrade ash to a version that resolves this vulnerability.

    Fixed in 3.29.3

Event History

Jun 23, 2026
CVE Published
via MITRE·06:21 PM
Data Sourced
via MITRE·06:21 PM
DescriptionWeakness
Data Sourced
via NVD·07:17 PM
DescriptionSeverityWeakness
Sep 24, 2026
Advisory Published
via GitHub·07:53 PM
Data Sourced
via GitHub·07:53 PM
DescriptionWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-55736?

CVE-2026-55736 has a medium severity rating of 5.9.

2

How does CVE-2026-55736 affect the Ash framework?

CVE-2026-55736 allows user-controlled modification of private action arguments in the Ash framework, compromising its intended security model.

3

Who is affected by CVE-2026-55736?

Users and developers utilizing the Ash framework version that is vulnerable to CVE-2026-55736 are at risk.

4

How do I fix CVE-2026-55736?

To fix CVE-2026-55736, ensure that private action arguments are not modifiable through user input by updating the framework or refactoring the affected code.

5

When was CVE-2026-55736 published?

CVE-2026-55736 was published on June 23, 2026.

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