EEF-CVE-2026-96581 CVE-2026-96581 GHSA-vw7c-67pf-gh96

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 Hex

Severity: 0.0 / 10; Unknown · CVSS 4.0
Exploit chance (EPSS): 0.26%; Chance of exploitation in the next 30 days. Higher than 17.54% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-639 Authorization Bypass Through User-Controlled Key
Fix: 3.37.2; Upgrade ash to this version or later

Description

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.

Under 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.

This issue affects ash: from 1.22.0 before 3.37.2.

Impact

A signed-in user of one tenant posts another tenant's record id to an upserting create action, receives that record's attributes, overwrites its upsert fields, and with the default upsert fields moves it into their own tenant.

Workarounds

Add 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.

Configurations

Reachable when a resource uses attribute multitenancy and exposes to callers of one tenant a create action with upsert? true that either upserts on the primary key (no upsert_identity) and accepts it, or upserts on an all_tenants? identity, and the caller knows or can enumerate a key belonging to another tenant (for example a serial integer id, or an id from a shared link or export).

Affected versions

Hex

Package	Vulnerable	Fixed in
ash	`>= 1.22.0, < 3.37.2`	`3.37.2`

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.37.2`

mix

{:ash, "~> 3.37.2"} # then: mix deps.update ash

Severity breakdown

CVSS 4.0 0.0

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

Attack vector: Network
Attack complexity: Low
Attack requirements: Present
Privileges required: Low
User interaction: None
Confidentiality (vulnerable system): High
Integrity (vulnerable system): High
Availability (vulnerable system): None
Confidentiality (subsequent systems): None
Integrity (subsequent systems): None
Availability (subsequent systems): None

Weakness

CWE-639: Authorization Bypass Through User-Controlled Key

The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

How to prevent it

Architecture and Design: For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
Architecture and Design, Implementation: Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Architecture and Design: Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.

References

Timeline

Oct 26, 2026 Published
Oct 26, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
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
EEF-CVE-2026-82749 Ash relationship parent(...) filter degrades to an IS NULL match when the parent field is unresolved, leaking scoped records	Not rated yet	Also affects ash

Credits: Will Townsend, Zach Daniel / Ash Project

Is this in your code?

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