Elixir CVE-2026-115274

Exploitation requires that the target application decode attacker-controlled JSON using Elixir's built-in JSON module (JSON.decode/1, JSON.decode!/1, or JSON.decode/3 with the default erlang:binary_to_integer integer decoder) on one of the affected versions (1.18.0-rc.0 through <1.18.6, 1.19.0-rc.0 through <1.19.7, or 1.20.0-rc.0 through <1.20.5). Applications generated by phx.new meet this condition by default, since phx.new sets JSON as the json_library and the generated endpoint passes it to Plug.Parsers, which decodes request bodies up to 8 MB before routing and authentication - so no authentication, user interaction, or non-default configuration is needed there. The limiting factors are: the app must actually parse untrusted JSON with this module (applications still using Jason are not affected, because Jason rejects integer literals longer than its default 1024-digit limit before conversion), impact is temporary CPU/memory exhaustion rather than crash or data loss, and a durable outage requires sustained request volume rather than a single request.

This is a genuine but moderate-priority availability issue, not an overblown high-CVSS entry. All signals point the same direction and are internally consistent: the supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L) describes a network-reachable, low-complexity, unauthenticated flaw whose only impact is partial availability loss (VA:L) - no confidentiality or integrity exposure - which matches the description of CPU/memory exhaustion rather than code execution. The score of 6.9 and the vuln.today 'this_month' decision label both signal a real issue that warrants scheduled patching rather than emergency action. No EPSS score and no CISA KEV entry are present in the input, so there is no evidence of active exploitation; the vendor advisory does contain a concrete, reproducible proof-of-concept, which lowers the effort required to attack but is not the same as observed in-the-wild use. The main factors tempering urgency are that impact is temporary scheduler starvation requiring sustained request volume for a durable outage, and that exposure is limited to applications on the affected Elixir versions that actually decode untrusted JSON with the built-in JSON module (notably default phx.new Phoenix apps). No data is missing in a way that conflicts with the vector - the signals are coherent.

An unauthenticated client sends a few-megabyte HTTP request body (default Plug.Parsers limit is 8 MB) containing JSON integer literals of roughly one million digits to a Phoenix application. Because Plug.Parsers decodes the body with the built-in JSON module before routing and authentication, the server spends about a second of CPU per request parsing each unbounded literal into a bignum, and sustained requests starve the BEAM schedulers. The vendor advisory publishes a working reproduction (a ~7 MB body of repeated '9' characters), so the barrier to reproducing the condition is low given the network vector and low attack complexity.