CVE-2026-82740 in ash
Summary
by MITRE • 09/01/2026
Improper Input Validation vulnerability in ash-project ash fails to enforce the outer array constraints on a doubly-nested {:array, {:array, type}} attribute, letting invalid input pass validation.
Ash.Type.apply_constraints/3 (lib/ash/type/type.ex) handled the {:array, {:array, type}} case by mapping only the inner {:array, type} constraints over each element, so constraints declared on the outer array (such as min_length, max_length, and nil_items?) were never applied. An attacker could submit an outer list that violates those constraints (too many elements, or nil entries where disallowed) and have it accepted and persisted. The fix enforces the outer array constraints and adds explicit handling for nil and non-list inputs.
This issue affects ash: from 2.16.1 before 3.32.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the Ash framework represents a critical failure in input validation logic, specifically within the type constraint enforcement mechanism for nested array structures. This flaw allows attackers to bypass security controls by submitting data that violates defined schema constraints, leading to potential integrity violations and unexpected application behavior. The issue is rooted in how the system processes doubly-nested arrays declared with the {:array, {:array, type}} specification, where the outer layer's validation rules are effectively ignored during the persistence phase.
At a technical level, the vulnerability resides in the Ash.Type.apply_constraints/3 function located within lib/ash/type/type.ex. When processing data structures that conform to nested array types, the implementation incorrectly maps only the constraints associated with the inner {:array, type} structure onto each individual element of the outer list. This architectural oversight means that validation rules applied directly to the outer array container are never executed. Specifically, constraints such as min_length and max_length, which dictate the permissible number of elements in a collection, along with nil_items? checks that prohibit null values within lists, are completely bypassed. Consequently, an input payload containing more or fewer items than allowed, or including prohibited nil entries, is accepted by the validation layer without triggering any errors or rejections.
The operational impact of this improper input validation is significant for applications relying on Ash for data persistence and integrity management. By allowing invalid inputs to pass through the validation stage, an attacker can persist malformed or maliciously crafted data into the underlying database. This undermines the reliability of the application's state machine and business logic that may depend on strict adherence to array size limits or non-null guarantees. In scenarios where these constraints are used for security purposes, such as limiting resource consumption by restricting list sizes, this flaw could facilitate denial-of-service conditions through excessive data ingestion. Furthermore, if downstream processes assume valid input based on the schema definition, they may encounter runtime errors or unexpected behavior when processing the unvalidated data, potentially leading to further exploitation vectors like injection attacks if the invalid data interacts with other system components without proper sanitization.
This vulnerability aligns with CWE-20 Improper Input Validation and falls under MITRE ATT&CK technique T1190 Exploit Public-Facing Application, as it involves manipulating input to bypass security controls in a web-facing framework. The flaw highlights the importance of comprehensive validation layers that account for all levels of nested data structures rather than focusing solely on leaf-level types. Developers must ensure that constraint enforcement logic traverses and validates every level of nesting according to the declared schema definitions.
To mitigate this risk, users should upgrade the Ash framework immediately to version 3.32.2 or later, where the fix explicitly enforces outer array constraints and adds robust handling for nil and non-list inputs. For systems that cannot be upgraded instantly, implementing additional custom validation layers at the API entry point can serve as a compensating control. These external validators should independently check list lengths and element validity before passing data to the framework's persistence layer. Regular security audits of type definitions and constraint configurations are also recommended to ensure that nested structures are handled with equal rigor across all levels of nesting, preventing similar oversights in future development cycles.