Skip to content

EEF-CVE-2026-97853 CVE-2026-97853 GHSA-6c27-994x-c52f

Unbounded allocation in decimal Decimal.round/3 driven by the places argument enables DoS

Not rated yet Hex
Severity
0.0 / 10
Unknown · CVSS 4.0
Exploit chance (EPSS)
0.14%
Chance of exploitation in the next 30 days. Higher than 3.16% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-789 Memory Allocation with Excessive Size Value
Fix
3.1.2
Upgrade decimal to this version or later

Description

Summary

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.

Details

Decimal.round/3 sets the target exponent to -places and do_round/5 materializes the coefficient at that exponent; context/2 only applies the precision afterwards.

  • Positive places (introduced in 1.3.0 by commit 7a83d27): digits ++ Enum.map(1..(exp - target_exp), fn _ -> ?0 end) followed by :erlang.list_to_integer/1 (lib/decimal.ex:2409 in 3.1.1). The list is built before list_to_integer/1 raises SystemLimitError for results over about 1.26 million digits, the BEAM integer size limit.
  • Negative places (since 1.4.0): :lists.duplicate(target_exp - exp, ?0) ++ digits (lib/decimal.ex:2385-2386 in 3.1.1).
  • Releases from 0.1.0 before 1.1.0: do_round (and in 1.0.1 split_coef) recurses once per decimal place for negative places; 1.0.1 also multiplies a power of ten by 10 on every iteration. Established by reading the code; these releases do not compile on current Elixir.

Measured on OTP 29 with 3.1.1, one call per fresh VM:

Call Time Peak VM memory
Decimal.round(Decimal.new("1.5"), -10_000_000) 0.25 s 0.8 GB
Decimal.round(Decimal.new("1.5"), -50_000_000) 1.2 s 5.5 GB
Decimal.round(Decimal.new("1.5"), 50_000_000) 2.1 s, then SystemLimitError 2.4 GB

In an elixir:1.20.4 container started with --memory=2g, either of the last two calls got the VM killed (exit status 137). Over HTTP (Plug and Bandit) a 34-byte JSON body carrying places: -50_000_000 returned after 1.25 s with server memory at 4.3 GB.

Proof of concept

Mix.install([{:decimal, "3.1.1"}])

# Allocates about 5.5 GB.
Decimal.round(Decimal.new("1.5"), -50_000_000)

# Builds a 50 million element list, then raises SystemLimitError.
Decimal.round(Decimal.new("1.5"), 50_000_000)

Impact

An attacker who controls the number of decimal places an application rounds to makes one Decimal.round/2,3 call allocate memory in proportion to that number. A value of 50 million needs about 5.5 GB, enough to get the BEAM VM killed on hosts with less memory and take down every request it serves.

Workarounds

Bound places before calling Decimal.round/2,3, for example to -34..34 or to the scales the application supports.

Affected versions

Hex

PackageVulnerableFixed in
decimal
>= 0.1.0, < 3.1.2
3.1.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.

decimal Hex → 3.1.2

mix
{:decimal, "~> 3.1.2"} # then: mix deps.update decimal

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Attack vector
Local
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
None
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
None
Availability (vulnerable system)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None

Weakness

CWE-789: Memory Allocation with Excessive Size Value

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

How to prevent it
  • Implementation, Architecture and Design: Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
  • Operation: Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
EEF-CVE-2026-32686
Unbounded exponent in decimal enables unauthenticated DoS
Medium Also affects decimal
GHSA-q7v9-x93c-xqv3
zip: Unbounded Symlink-Target Handling Can Abort Or Exhaust Memory During Extraction
High Same weakness, CWE-789
GHSA-9hj8-73fh-9963
zip: legacy Shrink/Reduce/Implode decoder: denial of service from attacker-controlled ZIP64 uncompressed size
High Same weakness, CWE-789
GHSA-j2w7-387v-m2rq
PhpSpreadsheet ODS Reader: Unbounded number-rows-repeated → CPU & Memory Exhaustion (DoS)
High Same weakness, CWE-789
GHSA-6wmf-3r64-vcwv
Crass : Large numeric exponents cause CPU and memory denial of service
High Same weakness, CWE-789
GHSA-5xm2-6676-qcp9
Pillow: APNG background disposal allocates full canvas before decompression bomb check
High Same weakness, CWE-789
GHSA-wf3x-273g-mvxv
devalue: Sparse arrays emitted by uneval cause eager allocation when evaluated
Low Same weakness, CWE-789
GHSA-r9w8-h9r3-54w4
devalue: Custom ArrayBuffer revivers can bypass typed-array allocation validation
High Same weakness, CWE-789

Credits: Eric Meadows-Jönsson, Peter Ullrich

Is this in your code?

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