CVE-2026-82740 Overview
CVE-2026-82740 is an improper input validation vulnerability [CWE-20] in the ash-project/ash Elixir framework. The flaw affects doubly-nested array attributes declared as {:array, {:array, type}}. The library's Ash.Type.apply_constraints/3 function applied only the inner array constraints to each element, silently ignoring the outer array's min_length, max_length, and nil_items? constraints. An attacker submitting an outer list with too many elements or disallowed nil entries could bypass validation and have the invalid data persisted. The issue affects ash versions from 2.16.1 before 3.32.2.
Critical Impact
Invalid input bypasses outer array constraints on nested array attributes, allowing malformed data to be accepted and persisted through Ash resource actions.
Affected Products
- ash-project/ash versions >= 2.16.1 and < 3.32.2
- Elixir applications using {:array, {:array, type}} attribute types with outer constraints
- Ash resources relying on min_length, max_length, or nil_items? for nested arrays
Discovery Timeline
- 2026-09-01 - CVE-2026-82740 published to NVD
- 2026-09-01 - Last updated in NVD database
Technical Details for CVE-2026-82740
Vulnerability Analysis
The vulnerability resides in lib/ash/type/type.ex within the apply_constraints/3 function. When a type is declared as {:array, {:array, type}}, the function pattern-matched the doubly-nested structure and delegated to apply_constraints({:array, type}, ...) for each inner element. This delegation passed item_constraints(constraints) to the inner call but never enforced the constraints declared at the outer level.
As a result, constraints such as min_length, max_length, and nil_items? on the outer array were unreachable code paths at validation time. The library also lacked explicit handling for nil and non-list values at the outer level, further widening the accepted input surface. Invalid values then propagated through resource actions and reached the persistence layer.
Root Cause
The root cause is a pattern-matching gap in Ash.Type.apply_constraints/3. The single clause handling {:array, {:array, type}} mapped only inner constraints across elements and discarded the outer constraint list. The clause also assumed term was always a list, so nil and non-list inputs escaped rejection.
Attack Vector
An authenticated or unauthenticated user, depending on the resource's action policy, submits an outer list that violates the declared outer constraints. Example violations include a list exceeding max_length, a list shorter than min_length, or a list containing nil entries when nil_items?: false. The Ash pipeline accepts the input, and downstream code operates on data that violates the declared schema.
# Security patch in lib/ash/type/type.ex
# fix: enforce outer constraints and handle nil for nested arrays
@spec apply_constraints(t(), term, constraints()) :: {:ok, term} | {:error, term()}
- def apply_constraints({:array, {:array, type}}, term, constraints) do
- type = get_type(type)
- map_while_ok(term, &apply_constraints({:array, type}, &1, item_constraints(constraints)))
+ def apply_constraints({:array, {:array, _}}, nil, _constraints), do: {:ok, nil}
+
+ def apply_constraints({:array, {:array, type}}, term, constraints) when is_list(term) do
+ inner_type = {:array, get_type(type)}
+ item_constraints = item_constraints(constraints)
+ nil_items? = Keyword.get(constraints, :nil_items?, false)
+ remove_nil_items? = Keyword.get(constraints, :remove_nil_items?, false)
+
+ {terms, errors} =
+ term
+ |> Enum.with_index()
+ |> Enum.reduce({[], []}, fn {item, index}, {items, errors} ->
+ case apply_constraints(inner_type, item, item_constraints) do
+ {:ok, value} ->
+ maybe_handle_nil_item(value, index, items, errors, nil_items?, remove_nil_items?)
+
+ {:error, new_errors} ->
+ new_errors =
+ new_errors
+ |> List.wrap()
+ |> Ash.Helpers.flatten_preserving_keywords()
Source: GitHub Commit c85ccff7
The patch adds a dedicated nil clause, guards the main clause with when is_list(term), and explicitly reads nil_items? and remove_nil_items? from the outer constraints during element processing.
Detection Methods for CVE-2026-82740
Indicators of Compromise
- Persisted records whose doubly-nested array attributes contain more elements than the declared max_length.
- Persisted records containing nil entries in nested array attributes declared with nil_items?: false.
- Application logs showing successful writes to resources whose schema would otherwise reject the payload.
Detection Strategies
- Audit Ash resource definitions for attributes typed as {:array, {:array, type}} and identify those with outer min_length, max_length, or nil_items? constraints.
- Write ad-hoc validation scripts that re-apply schema constraints against existing records and flag violations.
- Review inbound API request logs for payloads containing oversized nested arrays on affected endpoints.
Monitoring Recommendations
- Instrument Ash actions to log input payload sizes for nested array attributes and alert on outliers.
- Track dependency versions in build pipelines and fail builds using ash versions between 2.16.1 and 3.32.1.
- Monitor upstream advisories via the GitHub Security Advisory GHSA-v29m-p28g-w5fc and OSV EEF-CVE-2026-82740.
How to Mitigate CVE-2026-82740
Immediate Actions Required
- Upgrade ash to version 3.32.2 or later in mix.exs and run mix deps.update ash.
- Enumerate all resources using {:array, {:array, type}} attributes and review data written since the vulnerable version was introduced.
- Add explicit validation in custom changes or preparations for critical nested array attributes until the upgrade is deployed.
Patch Information
The fix is committed as c85ccff7 in the ash-project/ash repository and shipped in release 3.32.2. Full technical detail is available in the CNA advisory and the GitHub Security Advisory GHSA-v29m-p28g-w5fc.
Workarounds
- Add custom validations on affected attributes using Ash.Resource.Validation to enforce outer min_length, max_length, and non-nil element rules.
- Reject non-list and nil payloads at the API boundary (for example, in Phoenix controllers or AshJsonApi action inputs) before they reach apply_constraints/3.
- Restrict access to resource actions that expose vulnerable attributes until the upgrade completes.
# Configuration example - update ash dependency in mix.exs
# {:ash, "~> 3.32.2"}
mix deps.update ash
mix deps.get
mix compile --warnings-as-errors
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
