EEF-CVE-2026-82734 CVE-2026-82734 GHSA-mvvh-q33h-q62v
Non-finite Infinity/NaN decimal values bypass bounds constraints in Ash.Type.Decimal
- Severity
- 0.0 / 10
- Unknown · CVSS 4.0
- Exploit chance (EPSS)
- 0.19%
- Chance of exploitation in the next 30 days. Higher than 8.55% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-1284 Improper Validation of Specified Quantity in Input
- Fix
3.32.2- Upgrade ash to this version or later
Description
Summary
Improper Validation of Specified Quantity in Input vulnerability in ash-project ash allows an attacker to submit a non-finite decimal value that bypasses numeric bounds constraints or fails later operations on the value.
Ash.Type.Decimal cast input through Ecto's decimal cast in cast_input/2 and cast_stored/2 (lib/ash/type/decimal.ex) without checking that the resulting value is finite. Elixir's Decimal represents Infinity and NaN as valid structs, so a value such as "Infinity" or "NaN" passed casting and was persisted. Because NaN compares as false against every bound, min and max constraints do not reject it, and the stored special value later raises when used in Decimal arithmetic or is refused by the data layer, failing subsequent requests. The fix rejects any non-finite Decimal during casting.
This issue affects ash: from 1.28.0 before 3.32.2.
Affected versions
Hex
| Package | Vulnerable | Fixed in |
|---|---|---|
| ash | >= 1.28.0, < 3.32.2 |
3.32.2 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
ash Hex → 3.32.2
- mix
{:ash, "~> 3.32.2"} # then: mix deps.update ash
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
- Attack vector
- Local
- Attack complexity
- Low
- Attack requirements
- Present
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- Low
- Availability (vulnerable system)
- Low
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
Weakness
CWE-1284: Improper Validation of Specified Quantity in Input
The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.
How to prevent it
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
References
Advisories
Fixes and patches
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| EEF-CVE-2026-96581 An upsert on the primary key in Ash ignores attribute multitenancy, so one tenant can read, overwrite and take over another tenant's records | Not rated yet | Also affects ash |
| EEF-CVE-2026-114214 Loading a through relationship with a limit of 1 in Ash ignores the through path and returns unrelated destination records | Not rated yet | Also affects ash |
| EEF-CVE-2026-101028 Ash.count, Ash.exists and Ash.aggregate skip related resources' read policies in filters and sorts | Not rated yet | Also affects ash |
| EEF-CVE-2026-94201 Filtering an :atom attribute with unsafe_to_atom? can exhaust the BEAM atom table in Ash | Not rated yet | Also affects ash |
| EEF-CVE-2026-93477 Private action arguments can be set by user input on the bulk destroy and bulk update paths in Ash | Not rated yet | Also affects ash |
| EEF-CVE-2026-86338 Ash field policies do not filter-nil forbidden calculations and aggregates, enabling an information-disclosure oracle | Not rated yet | Also affects ash |
| EEF-CVE-2026-82752 Ash string length constraints count graphemes, so a combining-mark string of any size passes max_length | Not rated yet | Also affects ash |
| EEF-CVE-2026-82747 Ash.Policy.Authorizer returns records denied by a runtime read policy to any actor | Not rated yet | Also affects ash |
Credits: Jonatan Männchen / EEF, Peter Ullrich, Zach Daniel / Ash Project
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor