CVE-2026-97853: Unbounded allocation in decimal Decimal.round/3 driven by the places argument enables DoS
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"), -50000000) 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ericmj/decimalto a version that resolves this vulnerability.Fixed in 3.1.2
Event History
Frequently Asked Questions
Which applications are realistically exposed to this denial-of-service issue?
Applications using decimal versions from 0.1.0 before 3.1.2 are exposed if they pass an unbounded user-supplied number of decimal places or scale to Decimal.round/2 or Decimal.round/3. Applications that do not allow untrusted input to control the places argument are not described as exposed.
What does an attacker need to do to trigger the issue?
An attacker needs to cause a call to Decimal.round/2 or Decimal.round/3 with an extremely large positive or negative places value. No privileges or user interaction are required according to the supplied CVSS vector.
What is the impact of a successful attack?
Large places values can cause memory use to grow with the requested number of places rather than the final precision. For example, rounding 1.5 with -50,000,000 places can allocate about 5.5 GB and may exhaust memory and kill the BEAM VM; older releases may instead consume CPU once per requested decimal place.
What can be done if upgrading is not immediately possible?
Enforce a strict, application-appropriate bound on any places or scale value before passing it to Decimal.round/2 or Decimal.round/3. The limits introduced for CVE-2026-32686 do not protect the places argument.
Which version fixes the issue?
Upgrade decimal to version 3.1.2 or later. The affected range is decimal 0.1.0 before 3.1.2.