{"id":"CVE-2026-96581","title":"An upsert on the primary key in Ash ignores attribute multitenancy, so one tenant can read, overwrite and take over another tenant's records","summary":"Authorization Bypass Through User-Controlled Key vulnerability in ash-project ash allows a user of one tenant to read, overwrite and take over another tenant's records via an upserting create action.\n\nUnder attribute multitenancy, Ash.Ac…","severity":"high","cvss":7.6,"cvssVector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N","cvssSource":"cna","cwe":["CWE-639"],"vendor":"ash-project","product":"ash","affected":["ash >= 1.22.0 < 3.37.2","ash-project/ash >= 2333d01ddf37e5909769a513059b27e3183331c5 < c9f0cdb31e7c084def05f3f5be69dd7bb7721754"],"published":"2026-10-26","updated":"2026-10-26","sourceUpdated":"2026-10-26T07:20:07.186Z","source":"CVEORG","sourceUrl":"https://www.cve.org/CVERecord?id=CVE-2026-96581","references":[{"url":"https://github.com/ash-project/ash/security/advisories/GHSA-vw7c-67pf-gh96","label":"An upsert on the primary key in Ash ignores attribute multitenancy, so one tenant can read, overwrite and take over another tenant's records"},{"url":"https://cna.erlef.org/cves/CVE-2026-96581.html","label":"EEF CNA record for CVE-2026-96581"},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-96581","label":"OSV record EEF-CVE-2026-96581"},{"url":"https://github.com/ash-project/ash/commit/2333d01ddf37e5909769a513059b27e3183331c5","label":"Introducing commit 2333d01 in ash-project/ash"},{"url":"https://github.com/ash-project/ash/commit/c9f0cdb31e7c084def05f3f5be69dd7bb7721754","label":"Fix commit c9f0cdb in ash-project/ash"}],"tags":["cve.org"],"ingestedAt":"2026-10-26T08:21:41.800Z","slug":"CVE-2026-96581","body":"## Overview\n\nAuthorization Bypass Through User-Controlled Key vulnerability in ash-project ash allows a user of one tenant to read, overwrite and take over another tenant's records via an upserting create action.\n\nUnder attribute multitenancy, Ash.Actions.Create (lib/ash/actions/create/create.ex) and Ash.Actions.Create.Bulk (lib/ash/actions/create/bulk.ex) upserted on the primary key, or on an all_tenants? identity, without scoping the conflicting record to the request's tenant. A caller of a create action with upsert? true that accepts the primary key, supplying a record id from another tenant, updated that record's upsert fields and received all of its attributes in the result. With the default upsert fields the tenant attribute was written too, moving the record into the caller's tenant. Read and update policies do not run for upserts, and tenant-scoped create policies pass because the tenant is the caller's own.\n\nThis issue affects ash: from 1.22.0 before 3.37.2.\n\n## Affected\n\n- `ash >= 1.22.0 < 3.37.2`\n- `ash-project/ash >= 2333d01ddf37e5909769a513059b27e3183331c5 < c9f0cdb31e7c084def05f3f5be69dd7bb7721754`\n\n## Remediation\n\nRefer to the linked advisories for vendor-supplied fixes and affected version ranges.\n\n### Workarounds\n\nAdd upsert_condition expr(<tenant attribute> == ^tenant()) to every create action that upserts on the primary key or on an all_tenants? identity, and do not combine it with return_skipped_upsert?. An upsert into another tenant's record then fails with Ash.Error.Changes.StaleRecord (or is skipped in a bulk create) and leaves that record unchanged. This does not help on the Mnesia data layer, which ignores upsert conditions in affected versions.","depth":"twilight","depthScore":42,"depthScoreParts":{"impact":41.8,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}