Ash Framework CVE-2026-82742

Exploitation requires that untrusted input reaches Ash.Filter.Runtime.filter_matches/3 with a filter spanning at least two to-many relationship paths, and that the in-memory datasets for those relationships are large enough to trigger combinatorial memory growth - even two relationships with a few hundred rows each suffice. Applications that delegate all filtering to the database layer rather than invoking in-memory evaluation are entirely unaffected. Filters restricted to scalar attributes or a single to-many relationship are also not affected. The CVSS 4.0 AT:P (attack requirements: present) metric explicitly encodes the required deployment condition. There is no confidentiality or integrity impact under any conditions; the sole impact is availability of the Elixir node.

The vendor CVSS 4.0 score of 5.9 Medium reflects a required attack condition (AT:P) - the presence of multiple to-many relationships with sizeable datasets - which materially limits the exploitable attack surface compared to an unconditional DoS. Availability impact is High (VA:H) with no confidentiality or integrity exposure. EPSS data was not provided, and the vulnerability is not listed in CISA KEV, meaning no confirmed active exploitation is known at time of analysis. Real-world risk is strongly deployment-dependent: applications that expose Ash filter parameters to untrusted API consumers face a practical DoS vector requiring minimal attacker sophistication, while those constructing filters solely from trusted internal logic are at substantially lower risk. The vendor's AV:L vector choice suggests the primary threat model is a developer or operator misusing the API rather than a remote end user, though this distinction collapses when filter parameters are passed unsanitized from HTTP requests. Overall, this is a genuine availability risk in affected deployments but not a broad, indiscriminate threat.

An attacker identifies a web API endpoint that passes user-supplied filter parameters to Ash's in-memory filter evaluation and crafts a request filtering on two or more to-many relationships - for example, posts filtered simultaneously by tags and comments - against a resource holding hundreds of rows per relationship. Submitting this request triggers eager Cartesian product materialization in flatten_relationships/2, rapidly exhausting Elixir node heap and crashing the application. No public exploit code exists at time of analysis, but the mechanism is straightforward to reproduce from the advisory description alone.