CVE-2026-82749

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")).

Improper Validation of Specified Quantity in Input vulnerability in ash-project ash allows an attacker to store a value of arbitrary size in an attribute whose length constraint should bound it. Ash measures string length with Elixir's String.length/1, which counts Unicode graphemes, in the max_length and min_length constraints of Ash.Type.String (apply_constraints/2 in lib/ash/type/string.ex), in Ash.Resource.Validation.StringLength, and in the string_length expression function. A grapheme carries an unbounded number of combining marks, so a base character followed by a million combining acute accents is one grapheme and megabytes of data, and satisfies max_length: 2. Where the data layer imposes no independent limit (ETS, Mnesia, or a Postgres text column) the whole value is persisted, so an attacker can write an entire request body into an attribute declared with a small maximum and grow storage without bound. The counting unit also disagrees with the storage layer, which counts codepoints rather than graphemes, so a value accepted by the constraint can still be rejected or truncated by the column. A Postgres varchar(n) column bounds the value itself and is not exposed. This issue affects ash: from 0.10.0 before 3.33.0.

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.

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.