{
 "version": "https://jsonfeed.org/version/1.1",
 "title": "ash-project ash: all CVE events",
 "home_page_url": "https://patchwire.jonathanross.dev/products/ash-project--ash/",
 "feed_url": "https://patchwire.jonathanross.dev/feeds/products/ash-project--ash/all.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-114214/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-114214/",
   "title": "CVE-2026-114214 · ash-project ash · disclosed",
   "content_text": "Incorrect Authorization vulnerability in ash-project ash allows a client to read destination records unrelated to the source record through a through relationship.\n\nWhen a has_many relationship declared with through: was loaded for a single record with a limit of 1, or an unsorted has_one through relationship was loaded with a limit of 1, lateral_join?/4 in lib/ash/actions/read/relationships.ex chose the path that reads the destination without any filter linking it to the source. The load returned the first destination record by sort, or any other record with an offset. The read still runs the destination's policies but carries the relationship as accessing_from, so a client paging such a field (for example teachers(limit: 1, offset: n) through AshGraphql) can enumerate destination records that policies allow only when reached through that relationship.\n\nThis issue affects ash: from 3.24.0 before 3.37.1.",
   "date_published": "2026-10-25T19:47:30Z"
  },
  {
   "id": "tag:patchwire.jonathanross.dev,2026:CVE-2026-101028/disclosed",
   "url": "https://patchwire.jonathanross.dev/cve/CVE-2026-101028/",
   "title": "CVE-2026-101028 · ash-project ash · disclosed",
   "content_text": "Incorrect Authorization vulnerability in ash-project ash allows an actor to infer data in related records they cannot read via Ash.count/2, Ash.exists/2 and Ash.aggregate/3.\n\nAsh.Actions.Aggregate.run/4 (lib/ash/actions/aggregate.ex) applied only the root resource's read policy before running the aggregate query. The read path also applies each related resource's read policy to filter and sort references that cross a relationship, directly (for example comments.body) or through an aggregate over one, but the aggregate path skipped that step. A caller whose filter or sort reaches these functions, for example through Ash.Query.filter_input/2, an ash_lua script, or an AshAi tool offering count or exists results, can test conditions against related rows hidden from them and recover their existence and attribute values one query at a time. Ash.read/2 and its page counts are not affected.\n\nThis issue affects ash: from 2.6.0 before 3.34.6.",
   "date_published": "2026-10-09T07:01:06Z"
  },
  {
   "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"
  }
 ]
}