All vulnerabilities
CVE-2026-96581GHSA-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

ash-project ash
CVSS
7.6High
ExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)No scoreNo FIRST EPSS score in this snapshot yet
Fixed in3.37.2Fixed versionCVE List
Published26 Oct 2026Updated 26 Oct 2026CVE List

What fixes it

A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.

Description

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.

Text from CVE List

Affected versions 2

  • ashaffected: 1.22.0 before 3.37.2CVE List
  • ashaffected: 2333d01ddf37e5909769a513059b27e3183331c5 before c9f0cdb31e7c084def05f3f5be69dd7bb7721754CVE List

References 5