EEF-CVE-2026-55736 CVE-2026-55736 GHSA-f4hc-ppw9-4hhw
Private action arguments can be set by user input in Ash
- Severity
- 0.0 / 10
- Medium · CVSS 4.0
- Exploit chance (EPSS)
- 0.22%
- Chance of exploitation in the next 30 days. Higher than 13.04% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes
- Fix
3.29.3- Upgrade ash to this version or later
Description
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.
Configurations
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.
Affected versions
Hex
| Package | Vulnerable | Fixed in |
|---|---|---|
| ash | >= 3.0.0, < 3.29.3 |
3.29.3 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
ash Hex → 3.29.3
- mix
{:ash, "~> 3.29.3"} # then: mix deps.update ash
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
- Attack vector
- Local
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
The product receives input from an upstream component that specifies multiple attributes, properties, or fields that are to be initialized or updated in an object, but it does not properly control which attributes can be modified.
How to prevent it
- Implementation: If available, use features of the language or framework that allow specification of allowlists of attributes or fields that are allowed to be modified. If possible, prefer allowlists over denylists. For applications written with Ruby on Rails, use the attr_accessible (allowlist) or attr_protected (denylist) macros in each class that may be used in mass assignment.
- Architecture and Design, Implementation: If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
- Implementation: For any externally-influenced input, check the input against an allowlist of internal object attributes or fields that are allowed to be modified.
- Implementation, Architecture and Design: Refactor the code so that object attributes or fields do not need to be dynamically identified, and only expose getter/setter functionality for the intended attributes.
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| EEF-CVE-2026-96581 An upsert on the primary key in Ash ignores attribute multitenancy, so one tenant can read, overwrite and take over another tenant's records | Not rated yet | Also affects ash |
| EEF-CVE-2026-114214 Loading a through relationship with a limit of 1 in Ash ignores the through path and returns unrelated destination records | Not rated yet | Also affects ash |
| EEF-CVE-2026-101028 Ash.count, Ash.exists and Ash.aggregate skip related resources' read policies in filters and sorts | Not rated yet | Also affects ash |
| EEF-CVE-2026-94201 Filtering an :atom attribute with unsafe_to_atom? can exhaust the BEAM atom table in Ash | Not rated yet | Also affects ash |
| EEF-CVE-2026-93477 Private action arguments can be set by user input on the bulk destroy and bulk update paths in Ash | Not rated yet | Also affects ash |
| EEF-CVE-2026-86338 Ash field policies do not filter-nil forbidden calculations and aggregates, enabling an information-disclosure oracle | Not rated yet | Also affects ash |
| EEF-CVE-2026-82752 Ash string length constraints count graphemes, so a combining-mark string of any size passes max_length | Not rated yet | Also affects ash |
| EEF-CVE-2026-82747 Ash.Policy.Authorizer returns records denied by a runtime read policy to any actor | Not rated yet | Also affects ash |
Credits: Alfred Vié, Jonatan Männchen / EEF, Zach Daniel
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor