I tested the recently disclosed HTTP/2 “HPACK bomb” vulnerability (reference: https://thehackernews.com/2026/06/new-http2-bomb-vulnerability-allows.html) against Caddy with the coraza-caddy module (v2.5.0).
Although some sources suggested Caddy may not be affected, my testing indicates significant memory growth under a crafted HPACK attack.
Environment
- Caddy version: 2.11.4 - (tested it on 2.9.1 also)
- coraza-caddy: v2.5.0
- OS: Ubuntu 24.04
- Transport: HTTPS (HTTP/2 enabled by default)
Test Method
I used the publicly available PoC
Command:
python3 hpack_bomb.py --host example.com --port 443 --connections 3
Observed Behavior
Baseline memory usage was stable (~82 MB RSS). After starting the attack, memory usage rapidly increased:
[ 3.5s] RSS: 233.7 MB
[ 4.0s] RSS: 327.6 MB
[ 4.5s] RSS: 403.4 MB
[ 5.0s] RSS: 494.2 MB
[ 5.5s] RSS: 536.0 MB
[ 6.0s] RSS: 567.1 MB
...
Peak RSS observed: 567.1 MB
Memory remained elevated after the attack phase.
Mitigation Attempt
I tested the max_header_bytes setting.
By setting it to 16384, the issue was no longer reproducible, and memory usage remained stable during the attack.
However, this may not be an ideal solution in scenarios where larger headers are required (e.g., applications relying on large cookies or complex header structures). It effectively trades off functionality for protection, so it is unclear whether this should be considered a proper mitigation or just a workaround.
Questions
- Is coraza-caddy expected to mitigate this type of attack, or is this handled purely at the Caddy core level?
- Are there recommended mitigations (e.g., HTTP/2 settings, header size limits, Coraza rules) to prevent this?
- Is this considered a known limitation or a potential vulnerability?
I tested the recently disclosed HTTP/2 “HPACK bomb” vulnerability (reference: https://thehackernews.com/2026/06/new-http2-bomb-vulnerability-allows.html) against Caddy with the coraza-caddy module (v2.5.0).
Although some sources suggested Caddy may not be affected, my testing indicates significant memory growth under a crafted HPACK attack.
Test Method
I used the publicly available PoC
Command:
python3 hpack_bomb.py --host example.com --port 443 --connections 3Observed Behavior
Baseline memory usage was stable (~82 MB RSS). After starting the attack, memory usage rapidly increased:
Memory remained elevated after the attack phase.
Mitigation Attempt
I tested the max_header_bytes setting.
By setting it to 16384, the issue was no longer reproducible, and memory usage remained stable during the attack.
However, this may not be an ideal solution in scenarios where larger headers are required (e.g., applications relying on large cookies or complex header structures). It effectively trades off functionality for protection, so it is unclear whether this should be considered a proper mitigation or just a workaround.
Questions