hpax
Implementation of the HPACK protocol for Elixir. 🎴
View on Github
Activity
- Latest release
- 1mo ago
- Total releases
- 10
- Cadence
- ~5 months
- Last 12 months
- 2
Reach
- Downloads
- 43.1M
- Stars
- 27
Details
- License
- Apache-2.0
- First release
- Sep 22, 2021
| Version | Released | |
|---|---|---|
1.1.0
minor
| ||
1.0.4
patch
| ||
1.0.3
patch
1 CVE
CVE-2026-58226
EEF-CVE-2026-58226
GHSA-jj2p-32j7-whj2
Jul 06, 2026
Unauthenticated denial-of-service via unbounded HPACK integer decoding in hpax
High
Network
Low
None
None
SummaryInefficient 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. Affected versions
0.1.1
0.1.2
0.2.0
1.0.0
1.0.1
1.0.2
1.0.3
Fixed in
1.0.4
References Updated Jul 30, 2026 · Source: OSV.dev | ||
1.0.2
patch
1 CVE
CVE-2026-58226
EEF-CVE-2026-58226
GHSA-jj2p-32j7-whj2
Jul 06, 2026
Unauthenticated denial-of-service via unbounded HPACK integer decoding in hpax
High
Network
Low
None
None
SummaryInefficient 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. Affected versions
0.1.1
0.1.2
0.2.0
1.0.0
1.0.1
1.0.2
1.0.3
Fixed in
1.0.4
References Updated Jul 30, 2026 · Source: OSV.dev | ||
1.0.1
patch
1 CVE
CVE-2026-58226
EEF-CVE-2026-58226
GHSA-jj2p-32j7-whj2
Jul 06, 2026
Unauthenticated denial-of-service via unbounded HPACK integer decoding in hpax
High
Network
Low
None
None
SummaryInefficient 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. Affected versions
0.1.1
0.1.2
0.2.0
1.0.0
1.0.1
1.0.2
1.0.3
Fixed in
1.0.4
References Updated Jul 30, 2026 · Source: OSV.dev | ||
1.0.0
major
1 CVE
CVE-2026-58226
EEF-CVE-2026-58226
GHSA-jj2p-32j7-whj2
Jul 06, 2026
Unauthenticated denial-of-service via unbounded HPACK integer decoding in hpax
High
Network
Low
None
None
SummaryInefficient 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. Affected versions
0.1.1
0.1.2
0.2.0
1.0.0
1.0.1
1.0.2
1.0.3
Fixed in
1.0.4
References Updated Jul 30, 2026 · Source: OSV.dev | ||
0.2.0
minor
1 CVE
CVE-2026-58226
EEF-CVE-2026-58226
GHSA-jj2p-32j7-whj2
Jul 06, 2026
Unauthenticated denial-of-service via unbounded HPACK integer decoding in hpax
High
Network
Low
None
None
SummaryInefficient 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. Affected versions
0.1.1
0.1.2
0.2.0
1.0.0
1.0.1
1.0.2
1.0.3
Fixed in
1.0.4
References Updated Jul 30, 2026 · Source: OSV.dev | ||
0.1.2
patch
1 CVE
CVE-2026-58226
EEF-CVE-2026-58226
GHSA-jj2p-32j7-whj2
Jul 06, 2026
Unauthenticated denial-of-service via unbounded HPACK integer decoding in hpax
High
Network
Low
None
None
SummaryInefficient 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. Affected versions
0.1.1
0.1.2
0.2.0
1.0.0
1.0.1
1.0.2
1.0.3
Fixed in
1.0.4
References Updated Jul 30, 2026 · Source: OSV.dev | ||
0.1.1
patch
1 CVE
CVE-2026-58226
EEF-CVE-2026-58226
GHSA-jj2p-32j7-whj2
Jul 06, 2026
Unauthenticated denial-of-service via unbounded HPACK integer decoding in hpax
High
Network
Low
None
None
SummaryInefficient 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. Affected versions
0.1.1
0.1.2
0.2.0
1.0.0
1.0.1
1.0.2
1.0.3
Fixed in
1.0.4
References Updated Jul 30, 2026 · Source: OSV.dev | ||
0.1.0
initial
|