{"id":"EEF-CVE-2026-109821","summary":"Unbounded port parsing in URI.parse/1 enables CPU exhaustion denial of service in Elixir","details":"## Summary\n\nImproper Validation of Specified Quantity in Input vulnerability in the Elixir standard library's `URI` module allows an attacker who supplies a URL to cause a denial of service through CPU exhaustion.\n\n`URI.parse/1` converts the port component with `String.to_integer/1` in `split_authority/1` (`lib/elixir/lib/uri.ex`) without bounding its length, so a port of up to 1,262,592 decimal digits produces a bignum of that size and a longer one raises `SystemLimitError`. Rendering the parsed URI back to text (`URI.to_string/1`, `inspect/1`, logging, error formatting) converts the bignum with `:erlang.integer_to_binary/1`, which is quadratic on Erlang/OTP 27, 28 and 29.0: a 400,000-digit port renders in about 2.6 seconds and a 1 MB port in about 18 seconds. Ports above 65535 are also accepted.\n\nThis issue affects elixir: from 0.5.0 before 1.18.6, from 1.19.0-rc.0 before 1.19.7, and from 1.20.0-rc.0 before 1.20.5.\n\n## Details\n\n**1. Unbounded conversion**\n\n`split_authority/1` matches the port with the regex `(:(\\d*))?` and converts it with `String.to_integer/1`. Nothing bounds the digit run, so the VM builds an integer of up to 1,262,592 decimal digits (about 30 ms to parse 400,000 digits) and raises `SystemLimitError` above that, which escapes `URI.parse/1` instead of producing a `%URI{}`.\n\n**2. Render cost**\n\n`URI.to_string/1` renders the port with `Integer.to_string/1`, and `inspect/1` renders it the same way, both through `:erlang.integer_to_binary/1`. That conversion is quadratic on OTP 27, 28 and 29.0 and sub-quadratic from OTP 29.1 (https://github.com/erlang/otp/pull/11074). Per GHSA-8qw4-2chm-mvj2 it occupies a dirty CPU scheduler for its full duration.\n\n**3. Comparison with `URI.new/1`**\n\nErlang/OTP limited the port to 5 bytes in `:uri_string.parse/1` as part of GHSA-8qw4-2chm-mvj2. `URI.new/1` and `URI.new!/1` use `:uri_string` and get that limit on patched OTP versions. `URI.parse/1` does its own parsing and does not.\n\n**4. Reach**\n\nHeader-sourced URLs are bounded by HTTP server limits. Form and JSON body fields are not: Plug's default JSON body limit is 8 MB. One observed library path: a user-supplied URL passed to Req inside a Bandit request exits with the port in its arguments, and Bandit's error logging formats it, which took 2.8 seconds at 400,000 digits on OTP 28.\n\n## Proof of concept\n\n1. Build `url = \"http://example.com:\" \u003c\u003e String.duplicate(\"9\", 400_000)`.\n2. `URI.parse(url)` returns in about 30 ms.\n3. `URI.to_string(URI.parse(url))` takes 2,613 ms on OTP 27.3.4.18, 2,604 ms on OTP 28.5 and 108 ms on OTP 29.1.1. With 200,000 digits it takes 654 ms on OTP 27 and 28, so the cost grows 4x per doubling.\n4. The same digits placed in the path instead of the port parse and render in 1 ms or less.\n5. `URI.parse(\"http://example.com:65536\").port` returns `65536`, and a port of 1,262,593 digits raises `SystemLimitError`.\n\n## Impact\n\nAn unauthenticated client that submits a URL with a port of hundreds of thousands of digits makes the server build a bignum of that size, and each later rendering of the parsed URI costs seconds of CPU on Erlang/OTP 27, 28 and 29.0. Sustained requests exhaust CPU on applications that parse and log, store or echo user-supplied URLs.\n\n## Workarounds\n\nReject long URLs before parsing them, for example anything above a few kilobytes, and reject a parsed `port` above 65535 before rendering or using the `%URI{}`. `URI.new/1` is not affected on Erlang/OTP 27.3.4.17, 28.5.0.6, 29.0.6 and later, where `:uri_string` limits the port to 5 digits.\n\n## Configurations\n\nThe application parses an attacker-supplied URL with `URI.parse/1`, for example a URL field in a form or JSON request body, and then renders the result or a value containing it. The multi-second render cost requires Erlang/OTP 27, 28 or 29.0; on OTP 29.1 and later rendering a 1 MB port takes under a second. URLs in HTTP headers and the request line are bounded by the server's size limits.","aliases":["CVE-2026-109821","GHSA-327h-97cv-59xg"],"modified":"2026-10-30T09:15:36.905250202Z","published":"2026-10-30T08:54:07.752Z","database_specific":{"capec_ids":["CAPEC-130"],"cpe_ids":["cpe:2.3:a:elixir-lang:elixir:*:*:*:*:*:*:*:*"],"cwe_ids":["CWE-1284","CWE-400"]},"references":[{"type":"ADVISORY","url":"https://github.com/elixir-lang/elixir/security/advisories/GHSA-327h-97cv-59xg"},{"type":"WEB","url":"https://cna.erlef.org/cves/CVE-2026-109821.html"},{"type":"WEB","url":"https://github.com/erlang/otp/security/advisories/GHSA-8qw4-2chm-mvj2"},{"type":"WEB","url":"https://github.com/elixir-lang/elixir/commit/39801821eef2d06524e5ebf5a0e4b3c380ad23ae"},{"type":"FIX","url":"https://github.com/elixir-lang/elixir/commit/9a39d64a4473d02681c486bc70681c972479d32b"},{"type":"FIX","url":"https://github.com/elixir-lang/elixir/commit/b70f33a591b6ab8eb0fa4a7e00bac1c2ed4e0d58"},{"type":"FIX","url":"https://github.com/elixir-lang/elixir/commit/07d9abc3f3ac4c8d2ba8384bd102b6d6205b08b7"},{"type":"FIX","url":"https://github.com/elixir-lang/elixir/commit/d879b39d778fec2f475689573d5672720c4f2a21"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://github.com/elixir-lang/elixir","events":[{"introduced":"39801821eef2d06524e5ebf5a0e4b3c380ad23ae"},{"fixed":"9a39d64a4473d02681c486bc70681c972479d32b"},{"fixed":"b70f33a591b6ab8eb0fa4a7e00bac1c2ed4e0d58"},{"fixed":"07d9abc3f3ac4c8d2ba8384bd102b6d6205b08b7"},{"fixed":"d879b39d778fec2f475689573d5672720c4f2a21"}]}],"database_specific":{"source":"https://cna.erlef.org/osv/EEF-CVE-2026-109821.json"}}],"schema_version":"1.9.2","severity":[{"type":"CVSS_V4","score":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N"}],"credits":[{"name":"Eric Meadows-Jönsson","type":"FINDER"},{"name":"Eric Meadows-Jönsson","type":"REPORTER"},{"name":"José Valim","type":"REMEDIATION_DEVELOPER"},{"name":"Eric Meadows-Jönsson","type":"COORDINATOR"},{"name":"Jonatan Männchen / EEF","type":"ANALYST"}]}