{
 "version": "https://jsonfeed.org/version/1.1",
 "title": "ash-project ash: important CVE events",
 "home_page_url": "https://patchwire.jonathanross.dev/products/ash-project--ash/",
 "feed_url": "https://patchwire.jonathanross.dev/feeds/products/ash-project--ash/important.json",
 "authors": [
  {
   "name": "Patchwire"
  }
 ],
 "language": "en",
 "items": [
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-96581/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-96581/",
   "title": "CVE-2026-96581 · ash-project ash · disclosed",
   "content_text": "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.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.",
   "date_published": "2026-10-26T07:45:14Z"
  },
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-94201/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-94201/",
   "title": "CVE-2026-94201 · ash-project ash · disclosed",
   "content_text": "Ash stores :atom-typed attributes as strings and compares them as strings. When such an attribute is referenced in a filter, the comparison value is coerced through Ash.Type.Atom. Because the type defined no coerce/2 callback, coercion fell back to the default (cast_input/2), which calls String.to_atom/1 when the attribute is configured with the unsafe_to_atom?: true constraint.\n\nFiltering such an attribute with attacker-controlled strings therefore interned a new, permanent atom for every distinct value. Atoms are never garbage collected and the BEAM caps the atom table, so an actor who can supply filter values for a public, filterable :atom attribute declared with unsafe_to_atom?: true can exhaust the atom table and crash the node (denial of service). AshPaperTrail is a notable example: its version resources expose a public, filterable version_action_name atom attribute with unsafe_to_atom?: true by default.\n\nThe fix adds a coerce/2 to Ash.Type.Atom that never interns atoms — a comparison value is left as a string, since the type is stored and compared as a string. Setting the attribute from action input (cast_input/2, which still honors unsafe_to_atom?) is unchanged.\n\nThis issue affects ash: from 3.5.1 before 3.34.3.",
   "date_published": "2026-10-05T19:19:51Z"
  }
 ]
}