EUVD-2026-35439Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Primary rating from NVD.
CVSS VectorNVD
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
3DescriptionCVE.org
Uncontrolled Resource Consumption vulnerability in the Elixir standard library's Version module allows an attacker who controls a version string to cause a denial of service through CPU and memory exhaustion.
The version parser converts numeric version components (major, minor, patch and numeric pre-release/build identifiers) to integers without bounding their length. A single large all-digit component therefore forces a super-linear, non-yielding base-10 to arbitrary-precision integer conversion (String.to_integer/1, i.e. :erlang.binary_to_integer/1) that pins a BEAM scheduler, and a larger component raises an uncaught SystemLimitError that crashes the calling process. A single moderately sized string (around one megabyte) is enough; no authentication is required.
This is reachable from the public entry points Version.parse/1, Version.parse!/1, Version.match?/3, Version.compare/2, and Version.parse_requirement/1, which applications routinely call on untrusted input such as HTTP parameters, dependency-manifest fields, and package metadata.
This vulnerability is associated with program files lib/version.ex and program routines 'Elixir.Version.Parser':parse_digits/2.
This issue affects Elixir: from 1.5.0 before 1.20.1.
AnalysisAI
Denial of service in Elixir's standard library Version module (versions 1.5.0 through 1.20.0) allows any caller passing an attacker-controlled version string to exhaust CPU and memory or crash the calling BEAM process. The five public entry points - Version.parse/1, Version.parse!/1, Version.match?/3, Version.compare/2, and Version.parse_requirement/1 - pass numeric version components to :erlang.binary_to_integer/1 without length bounds, triggering super-linear arbitrary-precision integer conversion; a single ~1 MB all-digit component suffices. Applications routinely invoke these functions on untrusted input (HTTP parameters, package metadata), making the effective attack surface broader than the CVSS AV:L classification implies. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Technical ContextAI
The root cause resides in lib/elixir/lib/version.ex, specifically the Version.Parser private routine parse_digits/2 and convert_parts_to_integer/2. Prior to 1.20.1, all four numeric slots of a semantic version (major, minor, patch, and numeric pre-release identifiers) were fed without length validation to String.to_integer/1, which dispatches to the Erlang BIF :erlang.binary_to_integer/1. Because Elixir and Erlang integers are arbitrary-precision, converting a large decimal string requires super-linear time and heap allocation relative to digit count. At extreme sizes, the Erlang runtime raises a SystemLimitError, crashing the calling process unhandled. CWE-400 (Uncontrolled Resource Consumption) describes this class precisely: the parser fails to bound the computational cost of its input. The fix (commit c64417d72fd5c7d09e963ca3ac5fa2b140978d9e) introduces the compile-time constant @max_numeric_component_digits 14, rejecting any purely-numeric component exceeding 14 digits at the byte-size check before conversion is attempted. CPE affected: cpe:2.3:a:elixir-lang:elixir:*:*:*:*:*:*:*:* for versions 1.5.0 up to but not including 1.20.1.
RemediationAI
Upgrade to Elixir 1.20.1 or later, which is the vendor-confirmed fixed release. The upstream patch is commit c64417d72fd5c7d09e963ca3ac5fa2b140978d9e (https://github.com/elixir-lang/elixir/commit/c64417d72fd5c7d09e963ca3ac5fa2b140978d9e), and the security advisory is at https://github.com/elixir-lang/elixir/security/advisories/GHSA-w2h8-8x3g-278p. If an immediate upgrade to 1.20.1 is not feasible, applications should apply input validation at the boundary where version strings are received - specifically rejecting any string containing a dot-delimited numeric segment longer than 14 characters, or enforcing a hard total input length cap (e.g., 100 bytes). This guard should be applied before any call to Version.parse/1 or related functions. Trade-off: application-level length validation duplicates logic that 1.20.1 now handles natively, and may need adjustment if legitimate version strings with long non-numeric identifiers (e.g., build metadata) are expected. Blocking or sandboxing requests containing excessively large version query parameters at the WAF or API gateway layer is an additional compensating control with no application-code side effects.
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Module for Package Hub 15 SP7 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.3 | Affected |
| openSUSE Leap 15.4 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today