High · CVSS 7.6CVE-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 recordsCVE-2026-96581

Answer in brief

CVE-2026-96581 records a High severity (CVSS 7.6) vulnerability in An upsert on the primary key in Ash ignores attribute multitenancy, so one tenant can read, overwrite and take over another tenant's records. The current sources do not mark it as known exploited. The current feed maps ash-project/ash (generic), ash-project/ash-project/ash (generic). Check affected ranges and fixed versions before updating.

Analysis pending evidence review

HOL Guard separates source facts from reviewed analysis. See the methodology.

Published Oct 26, 2026Updated Oct 26, 2026Source checked Oct 26, 2026First seen by HOL Oct 26, 2026Material review Oct 26, 2026

Upstream Advisory

Affected scope and exposure questions

The current feed maps ash-project/ash (generic), ash-project/ash-project/ash (generic). Check affected ranges and fixed versions before updating.

Mapped affected packages and fixed versions
Package	Affected range	Fixed version
ash-project/ashgeneric	>=1.22.0 <3.37.2	3.37.2
ash-project/ash-project/ashgeneric	>=2333d01ddf37e5909769a513059b27e3183331c5 <c9f0cdb31e7c084def05f3f5be69dd7bb7721754	c9f0cdb31e7c084def05f3f5be69dd7bb7721754

Recommended response

Check inventory. Check lockfiles and deployed manifests for ash-project/ash, ash-project/ash-project/ash.

Review the reported fix. Source-reported workaround: 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.

Sources and claim methodology

Upstream source 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.

Quoted source text, attributed separately from HOL analysis.

An upsert on the primary key in Ash ignores attribute multitenancy, so one tenant can read, overwrite and take over another tenant's recordsCVE-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 recordsCVE-2026-96581

Key facts

Why this deserves its current priority

Affected scope and exposure questions

Recommended response

Evidence timeline and material changes

Sources and claim methodology

An upsert on the primary key in Ash ignores attribute multitenancy, so one tenant can read, overwrite and take over another tenant's recordsCVE-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 recordsCVE-2026-96581

Key facts

Why this deserves its current priority

Affected scope and exposure questions

Recommended response

Evidence timeline and material changes

Sources and claim methodology

Related CVEs