decimal

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.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

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.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.

Summary decimal doesn't bound the exponent on parsed input, so something like "1e10000000" is parsed fine but then explodes the memory to more than 7GB if you run e.g. Decimal.add(Decimal.parse("1e10000000"), 1) because for positive exp, the function tail-recurses with coef * 10 and exp - 1 per iteration, growing the bignum coefficient by one digit each step. In the worst case, one request is enough to OOM the BEAM.

Details

Decimal.new/parse/cast happily store huge exponents. After that, a bunch of core paths allocate proportional to exp:

• add/sub/div go through add_align, which calls pow10(exp1 - exp2) and builds a giant bignum (lib/decimal.ex:1734-1738, 1827).
• to_string/2 with :normal (also :xsd and the String.Chars impl) does :lists.duplicate(exp, ?0) (lib/decimal.ex:1506, 1513).
• to_integer/1 recurses coef * 10, exp - 1 once per unit of exp (lib/decimal.ex:1603-1605).
• round/3 does the same :lists.duplicate trick on the exp difference (lib/decimal.ex:1850, 1874).
• compare/3 with a threshold argument loops back into add/sub, so it's vulnerable too (lib/decimal.ex:331-332).

PoC

Any of these will hang or OOM the BEAM:

Decimal.add(Decimal.new("1"), Decimal.new("1e1000000000"))
Decimal.to_string(Decimal.new("1e1000000000"), :normal)
Decimal.to_integer(Decimal.new("1e1000000000"))
Decimal.round(Decimal.new("1e1000000000"))

Impact

Unauthenticated remote DoS. Anything that takes a user-supplied decimal (JSON, form field, Ecto :decimal field — basically everywhere) and then does arithmetic, rounding, to_integer, or to_string on it is exposed. One request can kill the node with a Out-of-Memory exception.

Note on the security fixes done in version 2.4.0

While 2.4.0 has the changes to mitigate this issue it's not considered as a patched version because it doesn't have them enabled by default.

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.