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 allA Guide to F5 Volumetric (Routed) DDoS Protection in F5 Distributed Cloud
Introduction F5 Volumetric (Routed) DDoS protection is a service in F5 Distributed Cloud (F5 XC) available for standard deployment and emergency use. F5 has over 100 engineers in its incident response team and 24/7 dedicated SOC analysts in 3 security operations centers around the world. This means F5 can help with the quick detection, mitigation, and resolution of Layer3-4 routed DDoS attacks. F5 Volumetric DDoS Protection stands out for several key reasons, especially for enterprises needing fully managed, hybrid, and multicloud-based DDoS mitigation with human-led and AI-assisted support. Here’s some of the ways Volumetric DDoS protection with F5 stands out: Fully Managed 24/7 Security Operations Center (SOC) F5’s SOC continuously monitors traffic for DDoS attacks in real time. Unlike purely automated solutions, human analysts intervene to fine-tune attack mitigation. The SOC provides expert-led response to mitigate complex or evolving threats. Hybrid Deployment Flexibility Cloud-based, always-on, or on-demand models for different use cases. Integrates with on-prem F5 BIG-IP solutions for a hybrid defense strategy. Helps reduce false positives by fine-tuning security policies. Advanced Attack Detection & AI-driven Mitigation Uses behavioral analytics to differentiate between legitimate traffic and attacks. Mitigates volumetric, application-layer, and multi-vector attacks. AI-assisted rules dynamically adapt to new attack patterns. Large-Scale Scrubbing Capacity Global scrubbing centers prevent volumetric DDoS attacks from overwhelming networks. Reduces the risk of downtime by filtering malicious traffic before it reaches critical infrastructure. F5 blocks volumetric DDoS attacks by denying offending /24 prefixes (via BGP) the ability to route to the Distributed Cloud scrubbing centers. (reference DevCentral) API-Driven and Customizable Security Policies Offers API integration for automated DDoS mitigation and security orchestration. Supports custom policies to protect specific applications from targeted attacks. Enterprise-Grade Support & Compliance Designed for large enterprises, financial institutions, and high-security industries. Meets compliance standards such as PCI DSS, GDPR, and SOC 2. Backed by F5’s global threat intelligence network. Logging & Observability Recently introduced is the capability to observe security events using external handlers via the Global Log Receiver (GLR) service. Organizations can use AWS S3 buckets, HTTP(s) servers, Datadog, Splunk, AWS CloudWatch, Azure Event Hubs and Blog Storage, Google Cloud Platform (GCP), Kafka Receiver, NewRelic, IBM QRadar, and SumoLogic, to store Distributed Cloud events. Then, they can use any platform to watch DDoS and other security events. If you’re curious how Distributed Cloud events look using ELK (Elasticsearch, Logstash, and Kibana), including how to set it up, see this related article in DevCentral. To configure Distributed Cloud to send events from Global Log Receiver, log in to the Distributed Cloud console and navigate to Shared Configuration > Manage > Global Log Receiver. Add a new item, and ensure the following: Log Type: Security Events Log Message Selection: Select logs from all namespaces For this example, I use Distributed Cloud App Connect to securely deliver events to an instance of ELK Stack running on AWS. To deliver the events locally with internal networking between Distributed Cloud and ELK Stack, I use a Customer Edge (CE) appliance, also in AWS. Having the CE deployed locally provides a secure endpoint with only local routing in the AWS VPC. ➡️ See the following documentation for how to deploy a CE in AWS. Next is to use App Connect with an HTTP Load Balancer. In this case, the origin pool is my ELK Stack receiver, and I’ve configured ELK to receive events over HTTP. Because I’ve configured the HTTP Load Balancer to be publicly available on the Internet to accept traffic from the Global Log Receiver, a Service Policy has been configured to restrict access to specific IP ranges. Although not shown, only traffic from the F5 Global Log Receiver designated IP ranges is allowed to access this load balancer. ➡️ See the following Allowlist reference documentation to learn which IP addresses to allow. To receive and process events in ELK, I’ve configured the following for logstash: root@3c99db3fa334:/etc/logstash/conf.d# cat 50-f5xc-logs.conf input { http { port => 8080 } } filter { json { source => "message" } } output { elasticsearch { hosts => ["localhost"] index => "f5xc-logs-%{+YYY.MM.dd}" } } In the ELK console, new messages are visible under Analytics > Discover. With messages arriving from GLR, we can now see many of the fields becoming searchable in the “message_parsed” hierarchy. Volumetric (Routed) DDoS events appear in the field “sec_event_type” with value “routed_ddos_sec_event”. The following alert and mitigation messages may be classified and searched as follows: New ongoing alert msg = “alert created” no “alert_ended_at” field present New and already completed alert msg = “alert created” alert_ended_at field present Completed ongoing alert msg = “alert completed” alert_started_at field present alert_ended_at field present New ongoing mitigation msg = “mitigation created” mitigation_ongoing = true no “mitigation_stop_time” field present New and already-completed mitigation msg = “mitigation created and completed” mitigation_ongoing = false migitation_stop_time field present Completed mitigation msg = “mitigation completed” mitigation_ongoing = false “mitigation_stop_time” field present Putting it all together in ELK, it’s easy to visualize each routed_ddos_sec_event with a filtered dashboard. Using the pie visual below allows security admins to decide what type of attacks have happened and whether any are still occurring. The dashboard visual can be added to other existing security dashboards in Kibana to provide a complete and robust overview of your security posture. Demo The following video further illustrates the capabilities of Volumetric (Routed) DDoS protection in Distributed Cloud. In it, I walk through the different ways protection can be activated and what some of the mitigation events and alerts look like in the console. 🎥 YouTube: https://youtu.be/jYiqog_tz2I Conclusion F5 Volumteric (Routed) DDoS protection combines integrated services to provide core-protect, auto-mitigation, security-analyst-initiated mitigations, and advanced deep packet inspection and filtering to provide the best protection available for Layer-3 and Layer-4 routed networking. Adding routed DDoS to networks is a simple onboarding process. F5 also provides emergency DDoS mitigation for customers who are actively being attacked. Observing DDoS attacks is not only available in the Distributed Cloud console but is also available directly in your monitoring platform of choice when using Global Log Receiver. Additional Resources 🎥 YouTube: Tour of Routed (Layer3 & Layer4) DDoS Protection in F5 Distributed Cloud How I did it - "Remote Logging with the F5 XC Global Log Receiver and Elastic" Deploy Secure Mesh Site v2 in AWS (ClickOps) Firewall and Proxy Server Allowlist Reference How To: Configure Global Log Receiver
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 L3 L4 L7 only
Big Hi to all of you, I am currently in the learning phase and have implemented L3/L4 DDoS protection using AFM. Now, I want to focus on L7 DDoS mitigation. However, I find Advanced WAF overwhelming, as it covers a vast range of topics, and I’m unsure where to begin. My goal is to concentrate solely on protecting against L7 DDoS attacks from WAF. Here are some key AFM settings I have implemented—let me know if anything is missing for L3/L4: IP Intelligence is applied at the global level. General Properties: Type: Forwarding (IP) Source Address: 0.0.0.0/0 Destination Address/Mask: x.x.x.x/29 Service Port: * Configuration: Protocol: All protocols Security Policy: DoS Protection Profile: DDoSProfile (Network and DNS enabled only) Now, moving on to my goal of implementing Bot Defense. Since Bot Defense applies only to HTTP service ports, do I need to set up two different Virtual Servers? Additionally, I want to apply a DoS profile that includes HTTP, along with Network and DNS protection (i.e., Network + DNS + HTTP).F5 BIG-IP Advanced WAF – DOS profile configuration options.
F5 BIG IP Advanced WAF is the perfect tool for detection and prevention of application Distributed Denial-of-Service (DDoS) attacks against a web application. This article will review the possible configurations of the dos profile also known as Adv WAF anti DDoS feature to stop those attacks.
What is the best option in Hybrid defender when there expected legal campaign (legal huge traffic)
Hello, What is the best option when using Hybrid defender in Auto Detection / Multiplier Based and at a certain time we expect high traffic to be reached to us As certain company is hosted with us they have normal traffic, but at certain time they publish a new service and expect huge number of users to access it So what is the best option in that scenario?DevCentral Top 5: Sep 8, 2014
But soft! What light through yonder window breaks? It is the east, and this week's edition of the DevCentral Top 5 is the sun. Yep, you guessed it. The top 5 is back...but unlike Shakespeare's Romeo and Juliet, this is no tragedy. Rather, it's a celebration of the most awesome articles you'll read anywhere on the Internet. Our DevCentral authors have been writing with freakish speed and determination, and they have turned out quality articles that are simply second to none. Choosing only five articles was a tough task given all the great content out there, but here's my take on the top articles since our last posting. F5 SOC Malware Summary Report: Neverquest I literally could have chosen five Lori MacVittie articles for this "top 5" but I resisted the urge and only chose one. In this article, Lori explains the details of a Trojan known as "Neverquest" that has been active since July 2013. Most of us get that warm, fuzzy, secure feeling when using 2-factor authentication because, you know, it's got 2 factors! Maybe automated malware has a shot at cracking one factor, but two? No way. Well, apparently Neverquest has found a way to automate the demise of our beloved 2FA. Lori does a magnificent job of explaining how Neverquest works, and then she discusses the amazing work that was completed by our F5 Security Operations Center in their analysis of this malware (in case you didn't know, F5 has a Security Operations Center that analyzes malware like this and provides amazing reports that are free for anyone to read). Lori provides links to the downloads of the executive summary as well as the full technical analysis of Neverquest. This one is not optional...if you care about anything at all, you gotta read this one. Leveraging BIG-IP APM for seamless client NTLM Authentication Michael Koyfman reminds us why we love the BIG-IP APM...transparent seamless authentication for users. In this article, Michael specifically discusses how to configure the APM to perform client NTLM authentication and use it in the context of sending a SAML assertion to the Office 365 service. This is a step-by-step masterpiece that shows you exactly what to do at every turn. In the end, you point your browser to the FQDN of the APM virtual server and you will be silently authenticated (let's be honest...silent authentication is a bucket-list item for each and every one of us). Michael also reminds us of the SSO options at the end of his article. Webshells Nir Zigler introduces us to Webshells (web scripts that act as a control panel for the server running them), and talks about some of the common uses for these scripts. But you know the story...scripts that were created for good can also be used for evil. After Nir explains all the valid uses for legitimate webshells, he takes us to a place where mere mortals dare not tread...through a webshell attack. He gives us an overview of how a webshell attack works, and then he explains some of the specific tools that are used for these nefarious actions. After walking through the power and functionality of an open source webshell called b374k, Nir shows how this tool can be used to attack an unsuspecting user. But have no fear! Nir finishes up the article by discussing the power of the BIG-IP ASM and how it will detect and prevent webshell attacks. Continuing the DDoS Arms Race How long have DDoS attacks been around, and why are they still news today? Because they are consistently one of the top attack vectors that companies face today. Shauntine'z discusses the DDoS arms race and provides some poignant statistics that remind us of the very real and credible DDoS threat. But the article doesn't stop there...it goes on to provide some excellent tips on what to do to strengthen your DDoS defense posture (it even has a well-placed picture of Professor John Frink...you gotta check this one out). Last, Shauntine'z reveals new features that are loaded in the latest release of the BIG-IP...version 11.6. The AFM and ASM have some new and exciting capabilities that are "must haves" for any company that is serious about securing their applications and critical business functions. (Editors note: the LineRate product has been discontinued for several years. 09/2023) Why ECC and PFS Matter: SSL offloading with LineRate We all know that sensitive data traverses our networks every day. We also know it's critically important to secure this information. We also know that SSL/TLS is the primary method used to secure said information. Andrew Ragone discusses SSL offloading and tells us why Elliptical Curve Cryptography (ECC) and Perfect Forward Secrecy (PFS) are great candidates for securing your information. He highlights the advantages of the software based LineRate solution, and gives great examples of why LineRate is the clear-cut winner over any existing software-based or hardware-based SSL/TLS offload solutions. Andrew also published another series of articles related to this very topic, and in these articles he walks you through the exact steps needed to configure SSL certificates and offload SSL on LineRate. On that subject...if you haven't had a chance to check out LineRate and learn all about the awesomeness that it is, do yourself a favor and visit
ASM L7DOS snmp traps
Dear, Do you know of any known issue about l7ddos snmp traps. For some reason they are not sent at all. The log entry in /var/log/dosl7/dosl7d.log is well present, but no snmp trap is sent. I checked the definition in the alertd config files and it looks like it is looking for a specific log entry in order to send the trap: alert.conf alert BIGIP_TS_TS_DOS_ATTACK_DETECTED_ERR { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.91"; } bigip_ts_error_maps.h 3 LOG_ERR 01310046 BIGIP_TS_TS_DOS_ATTACK_DETECTED_ERR "[SECEV] DoS attack: %s. HTTP classifier: %s, Operation mode: %s" But the problem is that when testing a l7ddos, no log entry can be found in /var/log/asm, there are only logs in /var/log/dosl7/dosl7d.log And it looks like the alertd does not process the later file (K14397) My client is running version 11.5.4 Thanks in advance for your assistance. Abdessamad
ASM L7DOS snmp traps
Dear, Do you know of any known issue about l7ddos snmp traps. For some reason they are not sent at all. The log entry in /var/log/dosl7/dosl7d.log is well present, but no snmp trap is sent. I checked the definition in the alertd config files and it looks like it is looking for a specific log entry in order to send the trap: alert.conf alert BIGIP_TS_TS_DOS_ATTACK_DETECTED_ERR { snmptrap OID=".1.3.6.1.4.1.3375.2.4.0.91"; } bigip_ts_error_maps.h 3 LOG_ERR 01310046 BIGIP_TS_TS_DOS_ATTACK_DETECTED_ERR "[SECEV] DoS attack: %s. HTTP classifier: %s, Operation mode: %s" But the problem is that when testing a l7ddos, no log entry can be found in /var/log/asm, there are only logs in /var/log/dosl7/dosl7d.log And it looks like the alertd does not process the later file (K14397) My client is running version 11.5.4 Thanks in advance for your assistance. Abdessamad
