Private action arguments can be set by user input in Ash
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.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-55736
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 4 Nov 2026, 21:24 UTC · Revision 1
Source evidence
Private action arguments can be set by user input in Ash
core-osv · Original sourcePublished 23 Jun 2026, 18:21 UTC
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.
osv:CVE-2026-55736
Complete source record
{
"id": "fde0716b8a4da745eaa2c692d37907a7dac1e5fb2b396c86cf65c0e763060052",
"url": "https://osv.dev/vulnerability/CVE-2026-55736",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "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.",
"evidence": "osv:CVE-2026-55736",
"products": [],
"severity": "medium",
"structured": {
"id": "CVE-2026-55736",
"aliases": [
"CVE-2026-55736",
"EEF-CVE-2026-55736",
"GHSA-f4hc-ppw9-4hhw"
],
"metrics": [
{
"type": "CVSS_V4",
"score": "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"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/ash-project/ash",
"type": "GIT",
"events": [
{
"introduced": "5967ed3a483ab949866e6d7b043b043e61703f17"
},
{
"fixed": "d9b3100219b3ea86d73202bf7368c03a7688efea"
},
{
"introduced": "0"
},
{
"fixed": "1ae2caddb91578469625c4257dc7a39233a726dd"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "5967ed3a483ab949866e6d7b043b043e61703f17"
},
{
"fixed": "d9b3100219b3ea86d73202bf7368c03a7688efea"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StandardRange"
},
{
"range": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.29.3"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StandardRange"
},
{
"range": [
{
"fixed": "d9b3100219b3ea86d73202bf7368c03a7688efea"
}
],
"source": "REFERENCES_COMMIT"
}
]
}
}
],
"versions": [
"v3.29.2",
"v3.29.1",
"v3.29.0",
"v3.28.0",
"v3.27.8",
"v3.27.7",
"v3.27.6",
"v3.27.4",
"v3.27.3",
"v3.27.2",
"v3.27.1",
"v3.27.0",
"v3.26.0",
"v3.25.2",
"v3.25.1",
"v3.25.0",
"v3.24.7",
"v3.24.6",
"v3.24.5",
"v3.24.4",
"v3.24.3",
"v3.24.2",
"v3.24.1",
"v3.24.0",
"v3.23.1",
"v3.23.0",
"v3.22.2",
"v3.22.1",
"v3.22.0",
"v3.21.3",
"v3.21.2",
"v3.21.1",
"v3.21.0",
"v3.20.0",
"v3.19.3",
"v3.19.2",
"v3.19.1",
"v3.19.0",
"v3.18.0",
"v3.17.1",
"v3.17.0",
"v3.16.0",
"v3.15.0",
"v3.14.1",
"v3.14.0",
"v3.13.2",
"v3.13.1",
"v3.13.0",
"v3.12.0",
"v3.11.3",
"v3.11.2",
"v3.11.1",
"v3.11.0",
"v3.10.1",
"v3.10.0",
"v3.9.0",
"v3.8.0",
"v3.7.6",
"v3.7.5",
"v3.7.4",
"v3.7.3",
"v3.7.2",
"v3.7.1",
"v3.7.0",
"v3.6.3",
"v3.6.2",
"v3.6.1",
"v3.6.0",
"v3.5.43",
"v3.5.42",
"v3.5.41",
"v3.5.39",
"v3.5.38",
"v3.5.37",
"v3.5.36",
"v3.5.35",
"v3.5.33",
"v3.5.32",
"v3.5.31",
"v3.5.30",
"v3.5.29",
"v3.5.28",
"v3.5.27",
"v3.5.26",
"v3.5.25",
"v3.5.24",
"v3.5.23",
"v3.5.22",
"v3.5.21",
"v3.5.19",
"v3.5.18",
"v3.5.17",
"v3.5.16",
"v3.5.15",
"v3.5.14",
"v3.5.13",
"v3.5.12",
"v3.5.11",
"v3.5.10",
"v3.5.8",
"v3.5.7",
"v3.5.6",
"v3.5.5",
"v3.5.4",
"v3.5.3",
"v3.5.2",
"v3.5.1",
"v3.4.73",
"v3.4.72",
"v3.4.71",
"v3.4.70",
"v3.4.69",
"v3.4.68",
"v3.4.67",
"v3.4.66",
"v3.4.65",
"v3.4.64",
"v3.4.63",
"v3.4.62",
"v3.4.61",
"v3.4.59",
"v3.4.58",
"v3.4.57",
"v3.4.56",
"3.4.56",
"v3.4.55",
"v3.4.54",
"v3.4.53",
"v3.4.51",
"v3.4.50",
"v3.4.48",
"v3.4.47",
"v3.4.46",
"v3.4.45",
"v3.4.44",
"v3.4.43",
"v3.4.42",
"v3.4.41",
"v3.4.40",
"v3.4.39",
"v3.4.38",
"v3.4.37",
"v3.4.36",
"v3.4.35",
"v3.4.34",
"v3.4.33",
"v3.4.32",
"v3.4.31",
"v3.4.30",
"v3.4.29",
"v3.4.28",
"v3.4.27",
"v3.4.26",
"v3.4.25",
"v3.4.24",
"v3.4.23",
"v3.4.21",
"v3.4.20",
"v3.4.19",
"v3.4.18",
"v3.4.17",
"v3.4.16",
"v3.4.15",
"v3.4.14",
"v3.4.13",
"v3.4.12",
"v3.4.11",
"v3.4.10",
"v3.4.9",
"v3.4.8",
"v3.4.7",
"v3.4.6",
"v3.4.5",
"v3.4.4",
"v3.4.3",
"v3.4.2",
"v3.4.1",
"v3.3.3",
"v3.3.2",
"v3.3.1",
"v3.3.0",
"v3.2.6",
"v3.2.5",
"v3.2.4",
"v3.2.3",
"v3.2.2",
"v3.2.1",
"v3.1.8",
"v3.1.7",
"v3.1.6",
"v3.1.5",
"v3.1.1",
"v3.0.16",
"v3.0.15",
"v3.0.14",
"v3.0.13",
"v3.0.12",
"v3.0.11",
"v3.0.10",
"v3.0.9",
"v3.0.8",
"v3.0.7",
"v3.0.6",
"v3.0.5",
"v3.0.4",
"v3.0.3",
"3.0.3",
"v3.0.2",
"v3.0.1",
"v3.0.0-rc.46",
"v3.0.0-rc.45",
"v3.0.0-rc.44",
"v3.0.0-rc.43",
"v3.0.0-rc.42",
"v3.0.0-rc.41",
"v3.0.0-rc.40",
"v3.0.0-rc.38",
"v3.0.0-rc.37",
"v3.0.0-rc.36",
"v3.0.0-rc.35",
"v3.0.0-rc.34",
"v3.0.0-rc.33",
"v3.0.0-rc.32",
"v3.0.0-rc.31",
"v3.0.0-rc.30",
"v3.0.0-rc.29",
"v3.0.0-rc.27",
"v3.0.0-rc.26",
"v3.0.0-rc.25",
"v3.0.0-rc.24",
"v3.0.0-rc.23",
"v3.0.0-rc.22",
"v3.0.0-rc.21",
"v3.0.0-rc.20",
"v3.0.0-rc.19",
"v3.0.0-rc.18",
"v3.0.0-rc.17",
"v3.0.0-rc.16",
"v3.0.0-rc.15",
"v3.0.0-rc.14",
"v3.0.0-rc.13",
"v3.0.0-rc.12",
"v3.0.0-rc.11",
"v3.0.0-rc.10",
"v3.0.0-rc.9",
"v3.0.0-rc.8",
"v3.0.0-rc.7",
"v3.0.0-rc.6",
"v3.0.0-rc.5",
"v3.0.0-rc.4",
"v3.0.0-rc.3",
"v3.0.0-rc.2",
"v3.0.0-rc.1",
"v3.0.0-rc.0"
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-55736.json"
}
}
],
"modified": "2026-10-28T02:30:39.611823954Z",
"provider": "osv",
"references": [
"https://cna.erlef.org/cves/CVE-2026-55736.html",
"https://github.com",
"https://osv.dev/vulnerability/EEF-CVE-2026-55736",
"https://repo.hex.pm",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55736.json",
"https://github.com/ash-project/ash/security/advisories/GHSA-f4hc-ppw9-4hhw",
"https://nvd.nist.gov/vuln/detail/CVE-2026-55736",
"https://github.com/ash-project/ash/commit/d9b3100219b3ea86d73202bf7368c03a7688efea",
"https://github.com/ash-project/ash"
],
"provider_metadata": {
"cwe_ids": [
"CWE-915"
],
"cna_assigner": "EEF",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55736.json"
}
},
"related_cves": [
{
"value": "CVE-2026-55736",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 507232,
"published_at": "2026-06-23T18:21:13.033+00:00"
}