The 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.
Improper 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.
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.
This 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.
"},{"base64":false,"type":"text/markdown","value":"Improper 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."}],"value":"Improper 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\nURI.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."}],"impacts":[{"capecId":"CAPEC-130","descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"An 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.
"},{"base64":false,"type":"text/markdown","value":"An 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."}],"value":"An 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."}]}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"PRESENT","attackVector":"NETWORK","baseScore":6.3,"baseSeverity":"MEDIUM","privilegesRequired":"NONE","providerUrgency":"NOT_DEFINED","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"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","version":"4.0","vulnAvailabilityImpact":"LOW","vulnConfidentialityImpact":"NONE","vulnIntegrityImpact":"NONE","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-1284","description":"CWE-1284 Improper Validation of Specified Quantity in Input","lang":"en","type":"CWE"}]},{"descriptions":[{"cweId":"CWE-400","description":"CWE-400 Uncontrolled Resource Consumption","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-30T09:02:51.828Z","orgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","shortName":"EEF"},"references":[{"name":"Unbounded port parsing in URI.parse/1 enables CPU exhaustion denial of service","tags":["vendor-advisory","related"],"url":"https://github.com/elixir-lang/elixir/security/advisories/GHSA-327h-97cv-59xg"},{"name":"EEF CNA record for CVE-2026-109821","tags":["related"],"url":"https://cna.erlef.org/cves/CVE-2026-109821.html"},{"name":"OSV record EEF-CVE-2026-109821","tags":["related"],"url":"https://osv.dev/vulnerability/EEF-CVE-2026-109821"},{"name":"Erlang/OTP advisory for the same issue in uri_string","tags":["related"],"url":"https://github.com/erlang/otp/security/advisories/GHSA-8qw4-2chm-mvj2"},{"name":"Introducing commit 3980182 in elixir-lang/elixir","tags":["related"],"url":"https://github.com/elixir-lang/elixir/commit/39801821eef2d06524e5ebf5a0e4b3c380ad23ae"},{"name":"Fix commit 9a39d64 in elixir-lang/elixir","tags":["patch"],"url":"https://github.com/elixir-lang/elixir/commit/9a39d64a4473d02681c486bc70681c972479d32b"},{"name":"Fix commit b70f33a in elixir-lang/elixir","tags":["patch"],"url":"https://github.com/elixir-lang/elixir/commit/b70f33a591b6ab8eb0fa4a7e00bac1c2ed4e0d58"},{"name":"Fix commit 07d9abc in elixir-lang/elixir","tags":["patch"],"url":"https://github.com/elixir-lang/elixir/commit/07d9abc3f3ac4c8d2ba8384bd102b6d6205b08b7"},{"name":"Fix commit d879b39 in elixir-lang/elixir","tags":["patch"],"url":"https://github.com/elixir-lang/elixir/commit/d879b39d778fec2f475689573d5672720c4f2a21"}],"source":{"discovery":"INTERNAL"},"title":"Unbounded port parsing in URI.parse/1 enables CPU exhaustion denial of service in Elixir","workarounds":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"Reject 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.
url = \"http://example.com:\" <> String.duplicate(\"9\", 400_000).URI.parse(url) returns in about 30 ms.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.URI.parse(\"http://example.com:65536\").port returns 65536, and a port of 1,262,593 digits raises SystemLimitError.1. Unbounded conversion
\nsplit_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{}.
2. Render cost
\nURI.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.
3. Comparison with URI.new/1
Erlang/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.
4. Reach
\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.
"},{"base64":false,"type":"text/markdown","value":"**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."}],"value":"1. Unbounded conversion\n\nsplit_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\n2. Render cost\n\nURI.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\n3. 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\n4. 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."}]}},"cveMetadata":{"assignerOrgId":"6b3ad84c-e1a6-4bf7-a703-f496b71e49db","assignerShortName":"EEF","cveId":"CVE-2026-109821","datePublished":"2026-10-30T08:54:07.752Z","dateReserved":"2026-10-23T14:00:01.560Z","dateUpdated":"2026-10-30T09:02:51.828Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"}