CVE-2026-97853 in decimal
Summary
by MITRE • 10/10/2026
Memory Allocation with Excessive Size Value vulnerability in ericmj decimal allows Denial of Service.
Decimal.round/3 builds the full result for the requested number of decimal places before the context precision (34 digits by default) is applied, so its cost grows with the places argument instead of with the size of the result. For positive places it appends places zero digits to the coefficient as a charlist before converting it to an integer, and for negative places it builds a charlist of -places zero digits. A single call such as Decimal.round(Decimal.new("1.5"), -50_000_000) allocates about 5.5 GB of memory, which can exhaust available memory and get the BEAM VM killed. The oldest releases instead loop once per decimal place, consuming CPU in proportion to places.
Any application that passes a user-supplied number of decimal places or scale to Decimal.round/2 or Decimal.round/3 without bounding it is exposed. The input limits added for CVE-2026-32686 do not cover the places argument.
This issue affects decimal: from 0.1.0 before 3.1.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified in the ericmj/decimal library represents a critical resource exhaustion flaw, specifically categorized under CWE-770 as Allocation of Resources Without Limits or Throttling. This issue arises within the Decimal.round function when processing requests for decimal precision that exceed reasonable bounds. The core technical failure lies in the algorithm's approach to constructing the result string before applying context constraints such as maximum precision. Instead of limiting memory allocation based on the final significant digits, the implementation allocates space proportional to the requested number of decimal places. For positive place values, the function appends a sequence of zero digits represented as a charlist prior to integer conversion. Conversely, for negative place values intended to round towards larger magnitudes, it constructs a charlist containing an equivalent count of zeros. This design choice means that computational cost and memory footprint scale linearly with the input argument rather than the size of the resulting numerical value, creating a direct pathway for resource abuse.
The operational impact of this flaw is severe Denial of Service against systems relying on the BEAM virtual machine to execute Elixir or Erlang applications utilizing this library. A single malicious call can trigger massive memory allocation events that rapidly exhaust system resources. For instance, invoking Decimal.round with a scale argument of negative fifty million digits results in approximately 5.5 gigabytes of memory being allocated instantly. This sudden spike in resource consumption often exceeds the available heap or physical RAM limits configured for the application process. Consequently, the BEAM virtual machine may be terminated by the operating system's out-of-memory killer to preserve overall system stability. In older versions of the library prior to specific patches, the vulnerability manifested differently but with equally detrimental effects; those implementations utilized a loop that executed once per decimal place, leading to excessive CPU consumption and prolonged unresponsiveness rather than immediate memory exhaustion. Both behaviors effectively render the application unavailable for legitimate users.
This vulnerability is particularly dangerous because it targets input validation gaps in applications that accept user-supplied precision or scale parameters without implementing strict upper bounds. Any service allowing end-users to specify how many decimal places should be retained during rounding operations is potentially exposed if they rely on this library version range from 0.1.0 up to but not including 3.1.2. The existing input limits introduced in related security updates, such as those addressing CVE-2026-32686, do not cover the places argument used by the round function, leaving a specific attack vector open despite other mitigations being in place. Attackers can exploit this by crafting requests with extremely large negative or positive scale values to trigger the excessive allocation behavior remotely if the rounding operation is part of an exposed API endpoint.
Mitigation strategies must focus on enforcing strict input validation at the application layer before any calls are made to the decimal library functions. Developers should implement a maximum allowable threshold for the number of decimal places, ensuring that user-supplied values do not exceed a reasonable limit consistent with business logic and system capacity constraints. For example, financial applications typically require no more than two or three decimal places, while scientific calculations might allow slightly higher precision but rarely beyond tens or hundreds of digits. By capping this input value before it reaches the Decimal.round function, organizations can prevent the allocation of excessive memory or CPU cycles. Additionally, upgrading to version 3.1.2 or later is essential as these releases contain fixes that address the underlying algorithmic inefficiencies and resource management issues associated with large scale arguments. Regular security audits should include testing for edge cases involving extreme numerical inputs to ensure that such vulnerabilities are identified and resolved before deployment in production environments.