CVE-2026-82746

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.

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, 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.