CVE-2026-82752

A vulnerability in the Ash library allows a user to set the value of a private action argument on the bulk destroy and bulk update paths. Arguments declared with public?: false should only be set by trusted server-side code, but the lack of a public? check on these paths enables modification from user input.

In Ash before version 3.33.4, field policies are documented to protect against filter-based information disclosure, but the nilling was applied only to attributes, not to calculations or aggregates. A user can reference a calculation or aggregate in a filter that they cannot see, and use the filter as an oracle to read the protected value (e.g., filter(secret_calc == "x")).

Incorrect Authorization vulnerability in ash-project ash returns records that a runtime read policy denies to any actor. When a resource has an access_type :runtime read policy (a check evaluated per record rather than compiled to a filter), Ash.Policy.Authorizer decides each record in check_result/1 by discarding impossible policy scenarios and inspecting what remains. When every scenario for a record was impossible, meaning no policy can authorize it and it must be forbidden, the empty-scenario branch instead kept the record and returned it as authorized. The fix forbids a record whose scenarios are all impossible. This issue affects ash: from 3.4.44 before 3.32.2.

In the ash library, an Incorrect Authorization vulnerability widens a relationship's parent(...) scoping filter to match unintended records when the referenced parent field cannot be resolved. The unresolved reference defaults to nil, causing predicates like org_id == parent(org_id) to become IS NULL matches, and guards like is_nil(parent(org_id)) activate unrestricted branches, returning records that should be excluded. The fix fails the read with an error when a parent(...) reference cannot be resolved.

Incorrect authorization vulnerability in ash authorizes an aggregate under one read action while computing it under another, so an aggregate can run with policies that do not match the action it was authorized against. This can lead to disclosure of information about records the actor cannot read.

In the ash library, a Missing Authorization vulnerability allows an actor to update records forbidden by resource policies through the atomic path of Ash.update_many/4. When an atomic strategy is used, the statement updates every row matched by primary key without applying policies, allowing modification of records belonging to other actors or tenants. The fix restricts the atomic path to data layers supporting changeset filters, authorizes each changeset, and merges the policy filter.

In the ash library, an Improper Access Control vulnerability lets a create action overwrite an existing record when the ETS or Mnesia data layer is used, because neither enforced primary-key uniqueness on insert. An actor who can set the primary key on a create can silently overwrite an existing record, destroying another entity's data without going through the update action or its policies. The fix rejects a create whose primary key already exists.

Not failing securely (failing open) vulnerability in ash skips an Ash.Reactor change when the guard controlling it raises, so a change meant to run does not. This can lead to security-relevant modifications being bypassed.

Uncontrolled resource consumption vulnerability in ash lets a slow asynchronous read spin a scheduler thread at full CPU while the framework waits for it. The AsyncLimiter.await_at_least_one/1 function used a tight loop with Task.yield(task, 0), causing busy-spinning.

In the ash library, an Uncontrolled Resource Consumption vulnerability lets an attacker exhaust node memory by matching a filter that spans multiple to-many relationships in memory. The flatten_relationships/2 function eagerly builds the full Cartesian product, leading to combinatorial memory growth. The fix streams the expansion lazily and short-circuits on the first matching scenario.