CVE-2026-82735 in ash
Summary
by MITRE • 09/01/2026
Uncontrolled Resource Consumption vulnerability in ash-project ash allows an attacker to force an expensive regular expression to run on input that a length constraint should have already rejected.
Ash.Type.String.apply_constraints/2 (lib/ash/type/string.ex) evaluated the :match regex regardless of the min_length and max_length constraints on the same attribute. Because the length check did not gate the regex, an over-length value that the length constraint rejects still had the pattern applied to it, so the length limit that would otherwise bound the work never constrained the regex input. Against a backtracking pattern this yields catastrophic regex evaluation on attacker-sized input, and even a linear pattern runs on arbitrarily large input, consuming CPU per request. The fix skips the :match regex whenever a length constraint is violated, making the two checks order-independent.
This issue affects ash: from 0.10.0 before 3.32.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in the Ash framework constitutes an Uncontrolled Resource Consumption flaw within its string type validation logic. Specifically, this security defect resides in the implementation of the Ash.Type.String.apply_constraints/2 function located in lib/ash/type/string.ex. The core technical issue arises from a logical sequencing error where regular expression matching is performed without regard to length constraints defined on the same attribute. In a properly secured system, input validation should follow a strict order or atomicity that ensures computationally expensive operations are only executed if simpler, cheaper checks pass first. However, in this affected version of Ash, the framework evaluates the :match regex pattern against user-supplied input even when that input exceeds the configured min_length and max_length boundaries. This design oversight means that length constraints fail to act as a gatekeeper for subsequent processing steps, allowing maliciously crafted inputs to bypass size-based protections before reaching more resource-intensive validation mechanisms.
From an operational perspective, this flaw leads directly to Denial of Service conditions through excessive CPU consumption. When an attacker submits input strings that are significantly longer than the allowed maximum length but still match a complex regular expression pattern, the system is forced to perform catastrophic backtracking or extensive linear scanning on data it should have rejected immediately. For patterns involving nested quantifiers or ambiguous structures, this results in exponential time complexity relative to the input size, effectively freezing application threads and exhausting server resources. Even for simpler regex patterns that do not exhibit exponential backtracking behavior, the system still incurs unnecessary computational overhead by processing arbitrarily large inputs instead of rejecting them at the length check stage. This inefficiency degrades service availability under load and can be exploited in automated attacks to overwhelm infrastructure components such as web servers or application containers without requiring authentication or privileged access.
This vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, specifically manifesting through algorithmic complexity issues that allow attackers to trigger disproportionate resource usage. In the context of the MITRE ATT&CK framework, this behavior corresponds to techniques associated with Impact and potentially Execution phases where adversaries leverage inefficient code paths to degrade system performance or cause service outages. The lack of input size gating before regex evaluation represents a common anti-pattern in web application development that undermines defense-in-depth strategies by allowing lower-level validation failures to propagate into higher-cost processing stages.
The issue impacts all versions of the Ash framework from 0.10.0 up to, but not including, version 3.32.2. To mitigate this vulnerability, developers must upgrade to a patched release where the application logic has been corrected to enforce length constraints prior to regex evaluation. The fix ensures that if an input violates min_length or max_length requirements, the :match operation is skipped entirely, rendering the two checks order-independent and preventing expensive computations on rejected inputs. Organizations relying on Ash for data validation should prioritize this update to restore proper resource management controls and prevent potential denial-of-service scenarios stemming from malformed or maliciously oversized payloads.