CVE-2026-58226: Elixir-Mint hpax DOS Vulnerability

CVE-2026-58226 Overview

CVE-2026-58226 is an inefficient algorithmic complexity vulnerability [CWE-407] in the hpax library, an HPACK (HTTP/2 header compression) implementation used by the elixir-mint project. The decoder places no upper bound on the value of HPACK variable-length integers or on the number of continuation octets it will process. An unauthenticated remote attacker who can deliver an HTTP/2 header block to a server using hpax can force superlinear CPU consumption, roughly O(N^2), from a small input. The issue affects hpax versions from 0.1.1 before 1.0.4.

Critical Impact
A small, attacker-controlled HTTP/2 header block can trigger CPU and transient memory exhaustion on any Elixir/Erlang server relying on hpax, enabling unauthenticated denial-of-service amplification.

Affected Products

elixir-mint hpax>= 0.1.1, < 1.0.4
Elixir HTTP/2 clients and servers built on Mint that link hpax transitively
Any BEAM-based service exposing an HTTP/2 endpoint through the affected hpax versions

Discovery Timeline

2026-07-06 - CVE-2026-58226 published to NVD
2026-07-06 - Last updated in NVD database

Technical Details for CVE-2026-58226

Vulnerability Analysis

The defect lives in Elixir.HPAX.Types:decode_remaining_integer/3, which decodes HPACK variable-length integers per RFC 7541 section 5.1. The function accumulates the integer as int + (value <<< m), shifting by seven additional bits per continuation octet. Decoding terminates only when a non-continuation octet is seen or when input is exhausted. It never checks whether the accumulated value has exceeded the RFC-mandated 2^32 - 1 bound.

Because BEAM integers are arbitrary precision, an attacker-supplied run of N continuation octets produces a bignum of O(N) bits. Each additional octet re-adds into an ever-larger bignum, so the aggregate work is superlinear at approximately O(N^2). A compact header block reaches the vulnerable path through the Elixir.HPAX:decode/2 entry point, converting a few kilobytes of network input into sustained CPU consumption on the target.

Root Cause

The root cause is missing bounds enforcement in variable-length integer decoding. RFC 7541 caps HPACK integers at 2^32 - 1, which requires at most five continuation octets when using a seven-bit prefix. The pre-patch decoder enforced neither the numeric ceiling nor a continuation octet ceiling, so a peer could stream continuation bytes indefinitely.

Attack Vector

An unauthenticated attacker opens an HTTP/2 connection to any service using a vulnerable hpax release and sends a HEADERS or CONTINUATION frame containing a crafted variable-length integer with a long tail of continuation octets. Server-side decoding consumes disproportionate CPU and memory relative to the transmitted bytes. Multiple parallel connections compound the effect and can render the service unresponsive.

elixir

## Decoding

# HPACK integers must fit in 0..2^32 - 1 (RFC 7541, section 5.1). We cap both
# the decoded value and the number of continuation octets we're willing to
# process, so that a peer cannot send a long run of continuation octets and
# force us into building an arbitrarily large bignums (a denial-of-service).
# 2^32 - 1 needs at most 5 continuation octets (7 bits each), so once the
# shift would grow past that the value can only exceed the maximum.
@max_integer (1 <<< 32) - 1
@max_shift 4 * 7

@spec decode_integer(bitstring, 1..8) :: {:ok, non_neg_integer(), binary()} | :error
def decode_integer(bitstring, prefix) when is_bitstring(bitstring) and prefix in 1..8 do
  with <<value::size(^prefix), rest::binary>> <- bitstring do

Source: GitHub commit 1ba4bb2 — the patch introduces @max_integer and @max_shift constants to cap both the decoded value and the number of continuation octets processed.

Detection Methods for CVE-2026-58226

Indicators of Compromise

HTTP/2 HEADERS or CONTINUATION frames containing header field length fields with unusually long runs of octets with the high bit set (0x80).
Sustained CPU spikes in BEAM scheduler threads correlated with active HTTP/2 connections.
Growing per-process heap size on Elixir HTTP/2 handler processes without a matching increase in request throughput.

Detection Strategies

Inventory Elixir and Erlang deployments and enumerate transitive dependencies on hpax versions >= 0.1.1 and < 1.0.4 using mix deps or SBOM tooling.
Instrument HTTP/2 ingress with per-frame size and decode-time metrics; flag decode operations whose CPU time is disproportionate to input size.
Deploy network monitoring rules on HTTP/2 traffic to detect header blocks whose variable-length integer fields contain more than five continuation octets.

Monitoring Recommendations

Track BEAM scheduler utilization and reduction counts on HTTP/2 acceptor processes; sudden sustained increases warrant investigation.
Alert on repeated HEADERS frames from a single source that consume abnormally high decode time.
Capture and retain HTTP/2 frame-level telemetry to enable retrospective analysis after CPU exhaustion events.

How to Mitigate CVE-2026-58226

Immediate Actions Required

Upgrade hpax to version 1.0.4 or later in all applications and rebuild release artifacts.
Audit direct and transitive dependencies for pinned versions of hpax and update any lockfiles.
Restart running Elixir releases so the patched decoder is loaded into memory.

Patch Information

The fix is available in hpax1.0.4. The commit at elixir-mint/hpax@1ba4bb2 caps the decoded integer at 2^32 - 1 and limits continuation-octet processing to a maximum shift of 4 * 7 bits, aligning the decoder with RFC 7541 section 5.1. Full advisory details are in the GitHub Security Advisory GHSA-jj2p-32j7-whj2 and the Erlang Ecosystem Foundation CVE listing.

Workarounds

Terminate HTTP/2 at an upstream reverse proxy or load balancer that enforces strict header block and frame size limits before traffic reaches the vulnerable decoder.
Apply rate limiting and per-connection CPU or request budgets on HTTP/2 endpoints to reduce amplification.
If HTTP/2 is not required, disable it and fall back to HTTP/1.1 on exposed listeners until the upgrade completes.

bash

# Update hpax to a fixed release
mix deps.update hpax
mix deps.get
mix deps | grep hpax  # verify version >= 1.0.4
mix release