Incorrect Authorization vulnerability in ash-project 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.

Ash.Actions.Aggregate groups aggregates by their {authorize?, readaction} and authorizes each group under that read action, but when building the data query it selected the action as opts[:action] || readaction || <primary read> (lib/ash/actions/aggregate.ex). When a caller passed an :action option, the aggregate query ran under that action while authorization had been computed for the group's own readaction. If the run action's read policies are more permissive than the authorized one, the aggregate (a count or sum) is computed over records the authorized action's policies would have excluded, disclosing information about data the actor cannot read. The fix runs the aggregate under the same readaction it is authorized against.

This issue affects ash: from 3.5.13 before 3.32.2.

Missing Authorization vulnerability in ash-project ash allows an actor to update records forbidden by resource policies through the atomic path of Ash.updatemany/4.

Ash.updatemany/4 runs as a single atomic statement (a data-layer updatemany, for example a SQL MERGE) whenever an atomic strategy is used and the data layer supports it. Ash.Actions.Update.UpdateMany (lib/ash/actions/update/updatemany.ex) took that path even under authorize?: true without applying the resource's policies, so the statement updated every row matched by primary key regardless of the policy filter that authorization would impose. An actor could therefore update records the policies forbid, such as rows belonging to another actor or tenant. The fix restricts the atomic path to data layers supporting changeset filters when authorizing, authorizes each changeset, and merges the resulting policy filter into each changeset so the statement only touches authorized rows.

This issue affects ash: from 3.29.0 before 3.32.2.

Not Failing Securely (Failing Open) vulnerability in ash-project ash skips an Ash.Reactor change when the guard controlling it raises, so a change meant to run does not.

An Ash.Reactor change step can be gated by where validations that decide whether the change runs. Ash.Reactor.ChangeStep (lib/ash/reactor/steps/changestep.ex) evaluated those guards in applywhereclauses/3, and applyvalidation rescued any exception into {:error, error}. The reduce treated that identically to a guard whose condition was simply not met and bypassed the change. So when a guard raises (for example on attacker-influenced input), a change that enforces a security-relevant modification is skipped rather than failing the step. The fix distinguishes a raised exception (now {:raised, error}) and halts the step with an error, failing closed.

This issue affects ash: from 3.0.0-rc.17 before 3.32.2.

Uncontrolled Resource Consumption vulnerability in ash-project ash lets a slow asynchronous read spin a scheduler thread at full CPU while the framework waits for it.

Ash.Actions.Read.AsyncLimiter.awaitatleastone/1 (lib/ash/actions/read/asynclimiter.ex) waited for concurrent async read tasks by polling each with Task.yield(task, 0) in a tight loop rather than blocking. While every outstanding task is still running (a slow related-data load or calculation), the loop returns immediately and repeats, busy-spinning and holding a BEAM scheduler at full CPU for the whole duration of the slow read; concurrent slow reads tie up further schedulers. The fix waits with Task.yieldmany (a non-blocking sweep followed by a blocking wait with timeout: :infinity), so the process sleeps until a task completes instead of spinning.

This issue affects ash: from 2.19.0 before 3.32.2.

Improper Neutralization of Special Elements in Data Query Logic vulnerability in ash-project ash allows an attacker to forge a relationship to a record they cannot name, and to recover the secret value used to look it up.

When managerelationship is used with onlookup: :relate on a belongsto relationship, the client-supplied lookup value is passed to Ash.Query.filter/2 without being cast to the attribute type. A nested map submitted where a scalar is expected is therefore interpreted as a filter predicate rather than a literal, so a lookup for a specific record becomes a query for any record matching a condition. The same path omits Ash.Query.limit(1), leaving Ash.readone/2 able to distinguish no match from one match from several, which turns comparison predicates into an oracle for the lookup value. Authorization is unaffected; the destination read policy still applies.

This issue affects ash: from 1.52.0-rc.11 before 3.31.1.