Elixir URI EUVD-2026-113757

The application must parse an attacker-controlled URL with URI.parse/1 (the independently-parsing function - URI.new/1 and URI.new!/1 use :uri_string and are NOT affected on OTP 27.3.4.17, 28.5.0.6, 29.0.6 and later, which cap the port at 5 digits) AND must subsequently render or echo the parsed %URI{} or a value containing it via URI.to_string/1, inspect/1, logging, or error formatting. The multi-second cost requires Erlang/OTP 27, 28, or 29.0; on OTP 29.1 and later the conversion is sub-quadratic and a 1 MB port renders in under a second, sharply limiting impact. The attacker input must also reach a path not bounded by small size limits: HTTP headers and the request line are capped by server limits, but form and JSON body fields are not (Plug's default JSON body limit is 8 MB). No authentication is required (PR:N). Ports above 65535, and up to 1,262,592 digits, are accepted; a longer port raises SystemLimitError that escapes URI.parse/1.

This is a genuine but moderate-priority denial-of-service issue, not a high-CVSS-but-trivial problem and not a widespread emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) correctly shows a network-reachable, unauthenticated, low-complexity vector with only partial availability impact (VA:L) and no confidentiality or integrity impact, and the AT:P (attack requirements present) flag reflects that exploitation depends on environmental conditions: the application must call URI.parse/1 on attacker-supplied input AND later render the result, running on Erlang/OTP 27, 28, or 29.0 where :erlang.integer_to_binary/1 is quadratic. No EPSS score and no CISA KEV entry are present in the input, so there is no signal of active exploitation; the vuln.today decision label is 'this_month', consistent with a patch-this-cycle rather than drop-everything posture. The GHSA advisory includes a detailed proof-of-concept but the input does not mark it as confirmed working exploit code. The main caveats: the per-request cost drops below one second on OTP 29.1+ (sub-quadratic), so the real-world severity is strongly dependent on the Erlang/OTP version deployed - a factor raw CVSS cannot capture - and only code paths using URI.parse/1 (not URI.new/1) are affected.

An unauthenticated client submits a URL field in a form or JSON request body (where length limits are generous - Plug's default JSON body limit is 8 MB) containing a host port of several hundred thousand decimal digits. The server's URI.parse/1 builds a multi-hundred-thousand-digit bignum, and when the application renders that parsed URI via URI.to_string/1, inspect/1, or error/access logging, :erlang.integer_to_binary/1 burns seconds of CPU on a dirty scheduler per request; sustained requests exhaust CPU. A detailed proof-of-concept exists in the vendor GHSA advisory (a 400,000-digit port renders in ~2.6 s on OTP 27/28).