CVE-2026-58226 in hpax
Summary
by MITRE • 07/06/2026
Inefficient Algorithmic Complexity vulnerability in elixir-mint hpax allows unauthenticated denial-of-service via unbounded HPACK integer decoding.
hpax decodes HPACK variable-length integers with no upper bound on the decoded value or the number of continuation octets. 'Elixir.HPAX.Types':decode_remaining_integer/3 accumulates the integer as int + (value <<< m), shifting by 7 more bits for each continuation octet and stopping only on a terminating octet or truncated input, never because the integer grew too large. Because BEAM integers are arbitrary precision, a run of N continuation octets builds an O(N)-bit bignum and re-adds into an ever-larger bignum on each step, so the total decoding cost is superlinear (about O(N^2)). An unauthenticated attacker who can send an HTTP/2 header block to a server using this decoder (reached through the 'Elixir.HPAX':decode/2 entry point) can supply a small header block that forces a large, attacker-controlled amount of CPU (and transient memory), a denial-of-service amplification.
This issue affects hpax from 0.1.1 before 1.0.4.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 07/06/2026
The vulnerability described represents a critical denial-of-service weakness in the elixir-mint hpax library that exploits inefficient algorithmic complexity through improper handling of HPACK integer decoding. This flaw exists within the Elixir.HPAX.Types:decode_remaining_integer/3 function which processes HPACK variable-length integers without implementing any upper bounds on either the decoded value or the number of continuation octets that can be processed. The implementation follows a pattern where each continuation octet contributes to an ever-growing integer through bit shifting operations, specifically accumulating values as int + (value <<< m) while shifting by seven more bits for each subsequent continuation octet.
The fundamental technical flaw stems from the absence of validation checks on the maximum size of decoded integers and the number of continuation octets that can be processed in a single decoding operation. In the BEAM virtual machine environment where Elixir runs, integers are arbitrary precision numbers that can grow without bound, which means that maliciously crafted input containing a sequence of continuation octets can cause exponential growth in computational requirements. The decoding process continues until either a terminating octet is encountered or the input is truncated, with no mechanism to prevent the integer from growing beyond reasonable limits. This creates a scenario where each additional continuation octet exponentially increases both the computational complexity and memory consumption required for processing.
The operational impact of this vulnerability is severe as it enables unauthenticated denial-of-service attacks that can amplify the attack vector significantly. An attacker who can send HTTP/2 header blocks to a server utilizing this vulnerable hpax library can craft relatively small header blocks that force the target server to perform massive amounts of CPU processing and temporary memory allocation. The computational cost grows superlinearly with the number of continuation octets, approximately following O(N^2) complexity where N represents the number of continuation octets in the malicious input sequence. This creates a substantial amplification effect where minimal network traffic can generate disproportionate computational overhead on the target system.
This vulnerability aligns with CWE-770, which addresses allocation of resources without limits or with inadequate limits, and demonstrates characteristics consistent with ATT&CK technique T1499.004 for Network Denial of Service. The issue affects hpax versions from 0.1.1 through 1.0.3, making it a widespread concern for systems using these library versions in HTTP/2 implementations. The root cause lies in the lack of input validation and resource limitation mechanisms during HPACK decoding operations, particularly within the Elixir.HPAX:decode/2 entry point that serves as the primary interface for processing HTTP/2 header blocks. Organizations using affected versions should immediately implement mitigations including library updates to version 1.0.4 or later, implementing input size limits on HTTP/2 header blocks, and applying rate limiting controls to prevent exploitation of this vulnerability through crafted header sequences.
The exploitability of this vulnerability is particularly concerning because it requires no authentication credentials and can be executed against any server that accepts HTTP/2 connections and utilizes the vulnerable hpax library. The attack surface includes web servers, reverse proxies, and any HTTP/2 endpoint that processes client-provided header blocks through the affected decoding mechanism. Security practitioners should prioritize patching this vulnerability as part of their remediation efforts, since it provides attackers with a straightforward method for consuming excessive computational resources and potentially causing service disruption or exhaustion across targeted systems.