CVE-2026-71562 in OTP
Summary
by MITRE • 09/01/2026
Improper Validation of Specified Quantity in Input vulnerability in Erlang/OTP inets httpc allows a malicious or compromised HTTP server to degrade availability by returning a numeric header whose value is a very long run of digits.
httpc_handler.erl converts the server-supplied Content-Length with list_to_integer/1 before comparing it against max_body_size, so the size check cannot protect the conversion, and the option defaults to nolimit in any case. The same unbounded conversion appears in httpc_response:format_response/1 for Content-Length and in httpc_response:get_ms_from_retry_after/1 for Retry-After, which is guarded only by a check that the first character is a digit. A value of up to roughly 1.26 million digits converts successfully and costs the requesting process hundreds of milliseconds of arbitrary-precision arithmetic per response. The conversion function is documented to accept integers of any size, so bounding the input is the caller's responsibility.
This issue affects OTP from OTP 17.0 before OTP 27.3.4.17, from OTP 28.0 before OTP 28.5.0.6, and from OTP 29.0 before OTP 29.0.6, corresponding to inets from 5.10 before 9.3.2.7, from 9.4 before 9.6.2.3, and from 9.7 before 9.7.2. Whether OTP before OTP 17.0, corresponding to inets before 5.10, is affected is unknown.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability described constitutes a significant availability risk within the Erlang/OTP inets HTTP client module, specifically affecting the httpc_handler and related response processing functions. This flaw stems from an improper validation of specified quantities in input data, allowing a malicious or compromised HTTP server to trigger resource exhaustion on the requesting process. The core technical issue lies in how the system handles numeric headers such as Content-Length and Retry-After without enforcing strict bounds before performing arithmetic conversions. When an attacker supplies a header value consisting of an extremely long sequence of digits, the Erlang runtime is forced to perform arbitrary-precision integer conversion using functions like list_to_integer/1. Unlike fixed-width integer types that would overflow or truncate large values, Erlang's bignum implementation allocates memory and CPU cycles proportional to the number of digits in the input string. Consequently, a header containing approximately 1.26 million digits can consume hundreds of milliseconds of processing time per response, effectively creating a denial-of-service condition by monopolizing the process scheduler and degrading system availability for legitimate users.
The operational impact is particularly severe because the existing security controls are insufficient to mitigate this vector. The httpc_handler.erl module attempts to protect against excessive body sizes by comparing the Content-Length header against a max_body_size configuration option before processing the body content. However, this check occurs after the numeric conversion has already taken place, rendering it ineffective as a preventative measure for CPU exhaustion. Furthermore, the default value for max_body_size is set to nolimit, meaning that even if the conversion were bounded later in the pipeline, there would be no cap on the size of data processed. Similar unbounded conversions are present in httpc_response:format_response/1 for Content-Length and in httpc_response:get_ms_from_retry_after/1 for Retry-After headers. The latter function only validates that the first character is a digit, which provides negligible protection against large integer inputs. This design oversight means that any HTTP server capable of injecting these oversized numeric headers can force the client to perform computationally expensive operations, leading to potential service degradation or complete unresponsiveness depending on the concurrency level and resource constraints of the host system.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to verify that input data meets expected size constraints before processing it in a computationally intensive manner. It also relates closely to CWE-787 Out-of-bounds Write if one considers memory allocation during bignum creation, though the primary impact here is CPU exhaustion rather than memory corruption or code execution. In terms of offensive security frameworks, this behavior maps to MITRE ATT&CK technique T1496 Resource Hijacking, where an attacker leverages system resources through inefficient processing logic to degrade performance for other users. The vulnerability highlights a common pitfall in functional programming languages like Erlang, where the flexibility of arbitrary-precision arithmetic is often assumed to be safe without explicit bounds checking by the caller. Developers must recognize that while language-level functions may accept inputs of any size, security-critical applications are responsible for enforcing reasonable limits on external data before invoking such operations.
Mitigation strategies require both immediate patching and long-term architectural adjustments. The primary remediation is to upgrade Erlang/OTP to a version where this issue has been addressed. Specifically, systems running OTP versions from 17.0 up to but not including 27.3.4.17 should be upgraded to at least 27.3.4.17. Similarly, users of OTP 28.x must upgrade to version 28.5.0.6 or later, and those on OTP 29.x must move to version 29.0.6 or newer. These updates correspond to inets module versions 9.3.2.7, 9.6.2.3, and 9.7.2 respectively for their respective major releases. For environments where immediate patching is not feasible, defensive programming practices should be implemented within the application layer. This includes implementing strict length checks on HTTP headers before they are passed to internal parsing functions, ensuring that numeric strings do not exceed a predefined maximum character count consistent with standard protocol limits. Additionally, configuring max_body_size to a sensible finite value rather than leaving it at the default nolimit can provide an additional layer of defense against excessive resource consumption during body processing, although this does not fully address the header conversion flaw itself. Organizations should also monitor for anomalous HTTP responses containing unusually large numeric headers as part of their intrusion detection systems to identify potential exploitation attempts in real-time.