HTTP/2 bomb attack - is BIG-IP vulnerable against CVE-2026-49975?
tl;dr The answer is: No Intro Two days earlier (June 2) Calif, a security firm from California, published a blog post about a new HTTP/2 DoS attack, that chains two attack techniques: a compression bomb and a Slowloris-style hold. I recommend to read this article, it contains a lot of deep dive information about the exploit. The attack basically goes after HPACK, the header compression in HTTP/2. A single byte sent over the network can turn into a full header allocation on the server—and that happens thousands of times in one request. Then the “hold” part comes in: a zero‑byte flow-control window that stops the server from ever releasing that memory. It amplifies tiny compressed header inputs into massive per‑request memory allocations via HPACK’s dynamic table, then exhausts server memory by using stalled flow control to prevent those allocations from ever being released. The attack works against many major web servers including: nginx Apache httpd Microsoft IIS Envoy Cloudflare Pingora This attack was assigned CVE-2026-49975. There are close to 1 million web servers running this vulnerable setup, according to Calif. The risk explained in plain english This attack is serious because it is a low-effort and therefore low-cost attack that works against most default http/2 configurations. Attackers can crash widely used web servers with minimum effort. Available mitigations Web servers that have the number of headers and the maximum decoded header size limited should be protected from this attack. NGINX 1.29.8+ adds max_headers directive with a default of 1000. Apache included a fix in mod_http2 in release v2.0.41. Microsoft IIS, Envoy, Cloudflare Pingora didn't release a patch at the time of writing. Testing - is BIG-IP vulnerable? All tests were conducted against BIG-IP v21.1 Best Bundle 3 GBps in AWS with a m5.xlarge EC2 instance with 4 cores and 16 GB memory. Good news first: The BIG-IP is not vulnerable to this attack Test setup For testing we used a BIG-IP v21.1 in AWS. We used a virtual server with an HTTP2 and an HTTP Profile with the default settings, Cliens-side and Server-Side SSL Profile, adjusted for TLS 1.3 and 1.2 with the required settings for HTTP2. This server had one iRule attached to forward traffic to a second virtual server. The second virtual server had again an HTTP2 and an HTTP Profile and a Client-Side SSL Profile, as well as an iRule that would respond HTTP 200 OK to any request. Additionally I started an instance of the F5 Application Study Tool. Important: We started our tests with the default values for Maximum Header Count of 64 in the HTTP profile and the default value for Concurrent Streams Per Connection of 10 in the HTTP/2 profile. The RFC 7540 for HTTP/2 recommends no less than 100 for the number of Concurrent Streams Per Connection to not unnecessarily limit parallelism. In a blog post the German IT news portal heise.de analyzed intermittent connection errors (ERR_HTTP2_PROTOCOL_ERROR) with their portal website were traced to Chrome sending a very large number of cookies as separate HTTP2 headers, exceeding the default Maximum Header Count in BIG-IP and causing dropped connections. heise.de resolved the issue by raising the header limit. First tests In our first test zero.bs attacked my BIG-IP with a HTTP2 GET Flood, running 100 bots with just 1 stream. This time the memory consumption went close to 40%, CPU usage even higher as in all other attacks before. We quickly went on the the second attack, a HTTP2 GET Flood, running 100 bots with just 10 streams. Both attacks did not seem to bother the BIG-IP a lot. CPU usage went up above 80%, but memory usage stayed below 20%. I could see around 3000 RPS on the second attack. On the third attack I increased the number of allowed headers to 1000 in the HTTP profile. zero.bs started another attack with 30 parallel HTTP2 streams and 1000 headers. On the third attack I increased the number of allowed headers to 1000 in the HTTP profile. zero.bs started another attack with 30 parallel HTTP2 streams and 1000 headers. The result was similar - high CPU consumption, slighlty more memory used. But still no risk of running out of memory. Taking our tests to the limits We did a couple of more tests, but let's fast forward to our final test. We used the maximum allowed values for Maximum Header Count of 4096 in the HTTP profile and for Concurrent Streams Per Connection of 256 in the HTTP/2 profile. This time the memory consumption went close to 40%, CPU usage even higher as in all other attacks before. Note: We observed that some of our control requests sent from a browser failed. The cause of that was that the CPUs had reached their limits while under attack by 100 bots with HTTP and HTTP2 profile values way above what is considered best practice. Final verdict and recommendations Conclusion: The conclusion of our tests led us to determine that the BIG-IP is not vulnerable to CVE-2026-49975. Security depends on configuration, traffic patterns, and software versions. We tested this attack on one virtual server. A carpet bombing attack on 10 or 20 virtual servers might have a totally different impact on the BIG-IP. We tested with low defaults and went to the maximum allowed values - keep your default settings sane and follow recommendations and best practices. Always use the latest LTS software to ensure you get the latest security patches. My key takeway: Test your environment regularly for vulnerabilites in your software and weaknesses in your DDoS defense strategy. Further reading I highly recommend reading this blog post by zero.bs that tracks their insights and test results related to this attack: One HTTP/2 Bomb to break them all
Log Source IPs for Traffic Sent to a BIG-IP Virtual Address Port it is not Listening on
Warning Before using this iRule, please assess an potential impacts to your BIG-IP based on it's current performance as iRules can negatively impact the BIG-IP and its traffic management processing. Related Log Message 011e0001 Limiting closed port RST response from 501 to 500 packets/sec for traffic-group /Common/traffic-group-1 Create iRule Create an iRule by navigating to Local Traffic > iRules > iRule List > Create Name: log_source_ip_to_closed_ports Paste the code below into the “Definition” box. Click Finished, and sync to peer if needed/desired. when CLIENT_ACCEPTED { set client_ip [IP::client_addr] # source IP variable set virtual_server_ip [IP::local_addr] # destination IP a variable set virtual_server_port [TCP::local_port] # destination port variable # Log information to /var/log/ltm log local0. "Connection attempted to unsupported port: $client_ip to destination $virtual_server_ip:$virtual_server_port" } Create Reject Virtual Server Create a new virtual server by navigating to Local Traffic > Virtual Servers > Virtual Servers List > Create Name: reject_vs Type: reject Source Address: 0.0.0.0/0 Dest. Address: 0.0.0.0/0 Service Port: 0 *All Ports Protocol: * All Protocols Optionally specifics the VLANs and Tunnels the virtual server should listen on. ltm virtual reject_vs { destination 0.0.0.0:0 mask any profiles { fastL4 { } } reject rules { new_irule } serverssl-use-sni disabled source 0.0.0.0/0 translate-address enabled translate-port enabled vlans { External } vlans-enabled vs-index 26 }
DDoS IPI List - Whitelist Update Domains
Problem this snippet solves: Legitimate IP address ranges and Domain Names of valid update servers. Additional info can be found: https://github.com/c2theg/DDoS_lists How to use this snippet: Add to IPI feeds. Security >> Network Firewall >> IP Intelligence : Feed Lists Create new list: DDoS_Feeds Add rule. Give a good name, IE: whitelist_update_servers List Type: whitelist Update frequency: 3600 Default Blacklist Category: (Create new one) Whitelisted_Source Admin / Password: <Leave Blank> Tested this on version: 13.0DDoS IPI List - Whitelist NTP Servers
Problem this snippet solves: Legitimate IP address ranges of valid NTP Servers. Additional info can be found: https://github.com/c2theg/DDoS_lists How to use this snippet: Add to IPI feeds. Security >> Network Firewall >> IP Intelligence : Feed Lists Create new list: DDoS_Feeds Add rule. Give a good name, IE: whitelist_ntp_servers List Type: whitelist Update frequency: 3600 Default Blacklist Category: (Create new one) Whitelisted_Source Admin / Password: <Leave Blank> Tested this on version: 13.0DDoS IPI List - Whitelist DNS Servers
Problem this snippet solves: Legitimate IP address ranges of valid DNS Servers Additional info can be found: https://github.com/c2theg/DDoS_lists How to use this snippet: Add to IPI feeds. Security >> Network Firewall >> IP Intelligence : Feed Lists Create new list: DDoS_Feeds Add rule. Give a good name, IE: whitelist_dns_servers List Type: whitelist Update frequency: 3600 Default Blacklist Category: (Create new one) Whitelisted_Source Admin / Password: <Leave Blank> Tested this on version: 13.0DDoS IPI List - Bogons
Problem this snippet solves: Bogon IP address ranges to block traffic from Additional info can be found: https://github.com/c2theg/DDoS_lists How to use this snippet: Add to IPI feeds. Security >> Network Firewall >> IP Intelligence : Feed Lists Create new list: DDoS_Feeds Add rule. Give a good name, IE: blacklist_bogon List Type: blacklist Update frequency: 432000 Default Blacklist Category: (Create new one) Blacklisted_Source Admin / Password: <Leave Blank> Tested this on version: 13.0
