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 allCyber Security Attack Mitigations with BIG-IP features
ArvinF is back to share mitigation options for Cyber Security Attacks with BIG-IP features! This article aim to bring these attack mitigations options much more visible and available. Cyber Security Attacks There are many types of Cyber Security Attacks. I will limit to the types that BIG-IP mostly encounter. Network Attacks Network attacks are aimed at compromising, disrupting, or gaining unauthorized access to an organization’s internal or external network, usually targeting communication protocols, devices, or services within the network. Web Application Attacks Web application attacks target weaknesses in web-based applications to gain unauthorized access to data, manipulate functionality, or exploit users. Web Application and Network Attacks are common and these can affect the Web application and network traffic processed thru F5 Virtual Servers and in some cases, affect the availability of the BIG-IP device itself. Malware Attacks Malware (malicious software) includes viruses, worms, Trojans, ransomware, and spyware designed to damage or gain control over a computer system. BIG-IP Cyber Security Attacks Mitigations But First, Finding "Help" I have always found it helpful to review the Help Tab of the feature and configuration. While logged in on the BIG-IP Configuration utility for the specific BIG-IP Application Security Manager (BIG-IP ASM/Adv WAF) or BIG-IP Advanced Firewall Manager (BIG-IP AFM) menu, the "Help" tab contains details of the relevant configurations. If you hit Launch, it opens on a new window. You can also click on Expand All to view each options documentation. On to the mitigation options.. Bot Defense Profile We have here the description of the Bot Defense Profile Templates where it provides details of each template - Relaxed, Balanced and Strict - on the Verification and Mitigation it will provide. Take note of the Relaxed template Browser verification as it uses "Challenge-Free Verification". This means clients that do not support Javascript such as mobile applications will not be prevented due to verification and is less intrusive. From K42323285: Overview of the unified Bot Defense profile https://my.f5.com/manage/s/article/K42323285 Challenge-Free Verification—The default value when Profile Template is set to Relaxed. The system performs header-based verification but does not perform JavaScript verification. The Balanced and Strict offers more stringent client verification. For the mitigation from Bot Defense to take effect, it should be in blocking mode. Relaxed Mode Defines a permissive security policy that performs basic non-intrusive verification of Browsers, strong verification of Mobile Apps using Anti-Bot Mobile Security SDK, blocks Malicious Bots and allows all other clients. Malicious Bots are detected mostly by using bot signatures. The mode provides basic protection level with very low risk of false positives. Balanced Mode Defines a moderate security policy that performs advanced verification of Browsers, strong verification of Mobile Apps using Anti-Bot Mobile Security SDK, blocks Malicious Bots, initiates CAPTCHA challenge for Suspicious Browsers, limits the total request rate produced by Unknown bots and allows Trusted and Untrusted Bots. Malicious Bots and Suspicious Browsers are identified by using both anomaly detection algorithms and bot signatures. This mode provides an advanced protection level with reduced latency impact because Browser verification is performed by injecting challenge in HTTP response. Strict Mode Defines a strict security policy that performs advanced verification of Browsers, strong verification of Mobile Apps using Anti-Bot Mobile Security SDK, and blocks all bots except Trusted Bots. This mode provides the most advanced and strict protection level using all capabilities of Bot Defense. Browser clients are not allowed to access unless they pass proactive verification. Mobile clients security access requires the use of Anti-Bot Mobile SDK. Here is a sample log for Bot Defense it is detecting a client that is classified as a "Suspicious Browser". The Bot Defense Profile that detected this bot request was configured with the "Relaxed" profile template. Here are sample Bot Traffic detected and actioned by a Bot Defense profile. Notice the Alarm and Block events. A detected "Suspicious Browser" is not blocked but generates an Alarm. A "malicious bot" is blocked DoS Protection Profile For the DoS Protection profiles, detection and mitigation can be configured thru TPS , Behavioral and Stress-based. The threshold for each configuration can be configured with Manual or Automatic thresholds. Manually configured TPS based detection looks at defined conditions and thresholds by Source IP, Device ID, Geolocation, URL and Site Wide and when exceeded, configured mitigation will take effect. The DoS Protection profile should be in Blocking mode for the mitigation to take effect. When using automatic threshold configuration in BIG-IP ASM/Adv WAF DoS Protection profile, the system sets the values using a wide range to begin with, then calculates the values using 7 days of historical data and sets threshold values to the highest levels during normal activity (to minimize false positives). Reference: K000138529: Understanding Automatic Threshold in BIG-IP ASM/Adv WAF DoS Protection profile The by Device ID detection option uses JavaScript to detect clients and requires a Bot Defense profile with Device ID mode to be configured. Here is the description of conditions from the TPS based detection configuration ================== Consider an IP as an attacking entity if either of the following conditions occur: Relative Threshold: TPS increased by: <traffic percentage> and reached at least <TPS> transactions per second OR Absolute Threshold: TPS reached: <TPS> transactions per second ================== Here is the description of conditions when TPS based detection is configured with Automatic Threshold ============== Consider an IP as an attacking entity if TPS reached an auto-calculated threshold in range <minimum TPS> - <upper limit TPS> transactions per second ============== For environments that have a mix of web and mobile application clients, only the Request Blocking option does not use Javascript to mitigate attacking clients. The Behavioral and Stress-based detection threshold can also be configured as Manual or Automatic and have the same configuration options TPS based detection. The difference is Server Stress is a requirement in this detection mode. Ensure that the DoS protection profile is in blocking mode. From the Online Help ============ Behavioral & Stress-based Detection In this area you can configure the system to prevent DoS attacks based on the server’s health condition. An attack is detected if the system finds the server to be under stress and either of the TPS thresholds are crossed. =========== Similar mitigation options are also available. Another section of Behavioral & Stress-based Detection is the Behavioral Detection and Mitigation where Bad Actor detection and mitigation can be configured From the Online Help ========= Bad actors behavior detection: Enables traffic behavior, server's capacity learning, and anomaly detection. Request signatures detection: Enables signatures detection. Use TLS fingerprints identification: Allows the system to distinguish between bad and good actors behind the same IP (NAT). When disabled (default), any attack behind the NAT treats all users behind the NAT as attackers. ========= Do take note of Request signatures detection and Use TLS fingerprints identification as these options are useful in identifying attacking clients behind a NAT device by way of TLS fingerprint and clients with specific HTTP signatures. Here is the Bad actors behavior detection mitigation descriptions. Review the protection levels and use what is appropriate as per your needs. Mitigation: No mitigation: Learns and monitors traffic behavior, but no action is taken. Conservative protection: If «Bad actors detection» enabled, slows down and rate limits requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. If «Request signatures detection» enabled, blocks requests that match the attack signatures. Standard protection: If «Bad actors detection» enabled, slows down requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. Rate limits requests from anomalous IP addresses and, if necessary, rate limits all requests based on the servers health. Limits the number of concurrent connections from anomalous IP addresses and, if necessary, limits the number of all concurrent connections based on the server's health. If «Request signatures detection» enabled, blocks requests that match the attack signatures. Aggressive protection: If «Bad actors detection» enabled, slows down requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. Rate limits requests from anomalous IP addresses and, if necessary, rate limits all requests based on the servers health. Limits the number of concurrent connections from anomalous IP addresses and, if necessary, limits the number of all concurrent connections based on the server's health. Proactively performs all protection actions (even before an attack). Increases the impact of the protection techniques. If «Request signatures detection» enabled, blocks requests that match the attack signatures. Increases the impact of blocked requests. Regarding Server Stress There are a couple of locations where Server Stress can be observed. A spike in Server Stress will trigger Behavioral and Stress-based DoS detection and mitigation if configured. Protected Objects List This is under Security ›› DoS Protection : Protected Objects : Protected Objects List This menu is available when you have BIG-IP AFM provisioned in this sample, notice the Server Stress is at 100/100 - this means the backend server is Stressed and the latency of Server response is High. The protected object's attack status is "red" signaling an attack is ongoing and being mitigated. On this sample, the detected attack is ongoing and the server stress value has gone down to 55/100. The request rate also shows the connections per second and has gone down. Behavioral DoS Dashboard Under the Statistics menu, click on Dashboard Select Behavioral DoS in the Dashboard options Review Server Stress Here are sample DoS Application Events generated thru a DoS protection profile TPS Based detection and mitigation Behavioral detection and mitigation It provides insight which DoS "Threshold condition" was exceeded and what "Mitigation" was applied to the detected "Attack (Attack ID)" also noting the start and end of the attack. Inspecting these events will help in figuring out a threshold you may apply. DoS Dashboard under Security Reporting When looking for details of the attack, the DoS Dashboard under Security Reporting provides insight on the detected attack and related entities and statistics. In this sample, the detected attack was triggered thru App Behavioral and mitigated with Behavioral mitigation In this sample, notice the "transaction outcomes" shows "Blocked Bad Actor" which means the transactions were blocked by Bad Actor detection and mitigation configuration in the DoS protection profile. IP reputation , IP Intelligence license - must have! During DDoS attacks, it is very likely that the some of the source IP addresses will have bad IP reputation. Having the IP Intelligence license available in the BIG-IP will provide mitigation for matched IP addresses. IP Intelligence can be used in BIG-IP LTM (iRules and LTM Policy), AFM (IP Intelligence Policy) and ASM/Adv WAF (Security Policy) configurations. Refer to the following links on sample iRule configurations. https://clouddocs.f5.com/api/irules/IP__reputation.html https://clouddocs.f5.com/api/irules/IP__intelligence.html Note that the IP intelligence feature requires an add-on license. Contact your F5 or Partner salesperson for details on ordering the license. Cyber Security Attack Scenarios and Recommendations As introduced earlier, here are Cyber Security Attack Scenarios that BIG-IP deployments encounter and corresponding mitigation options and configuration recommendations. These sample scenarios will be helpful in finding initial mitigation options using BIG-IP features should it match your deployment configuration. Scenario: DDoS attack on a F5 Virtual Server fronting a web application and the BIG-IP have ASM/Adv WAF license. There are no DoS protection and Bot Defense profile configured on the Virtual Server. Recommendations: For the DoS Protection profile, configure TPS and Behavioral and Stress based Detection. Set Detection Thresholds and mitigations for both options as per your needs. You can monitor the traffic pattern on the Virtual Server you are protecting. Consider the clients that access the web application. If the clients are web browsers and mobile application users, use non Javascript (JS) based detection and mitigations. This will allow mobile application clients that do not support Javascript challenges to access the protected web application and ensure they are not blocked by Javascript challenges or mitigations. Another detection method is thru Bad Actor detection configuration under Behavioral and Stress Based Detection menu. This feature slows down and rate limits requests from anomalous IP addresses based on its anomaly detection confidence and the server's health. Automatic Threshold can also be configured for TPS based detection. For more information on HTTP enabled DoS Protection configured with Automatic Threshold, refer to K000138529: Understanding Automatic Threshold in BIG-IP ASM/Adv WAF DoS Protection profile For the Bot Defense profile, configure the Relaxed Profile template. This does not use Javascript challenges for detecting end clients and will allow mobile application clients that do not support Javascript to access the protected web application. Configure a logging profile that logs remotely to trusted logging server for DoS protection and Bot Defense events. Scenario: DDoS attack on a F5 Forwarding IP or Performance Layer 4 Virtual Server processing network traffic. Recommendations: Ensure DoS mitigations are available to protect the network traffic. BIG-IP AFM have DoS Attack types for Network Based DoS and can be set to Mitigate to detect and mitigate/drop excess packets for the matched attack type. These DoS Attack types can be configured with Fully Manual or Fully Automatic threshold. You should set detection and mitigation thresholds as per your needs. It is important to review traffic statistics and pattern on the Virtual Server you are protecting. AFM threshold values are in EPS - Events Per Second, synonymous to Packets Per Second and the observed traffic pattern can be the basis of the manually configured thresholds. Another method of defining the threshold is thru "Threshold Sensitivity" where the BIG-IP system CPU usage and traffic pattern is the basis. When AFM DoS attack types are configured with Fully Automatic, it uses the "Threshold Sensitivity" configuration. For BIG-IP Advanced Firewall Manager (AFM) systems protecting networks against Distributed Denial of Service (DDoS) attacks, DoS Auto Threshold sensitivity can be configured for system-wide thru Device Protection and per DoS Protection Profile. A setting of High will be more sensitive to changes in BIG-IP System CPU usage and traffic. A setting of Medium is the default configuration. A setting of Low will be less sensitive to changes in BIG-IP System CPU usage and traffic. From the BIG-IP Configuration utility, navigate to: For System Wide: Security ›› DoS Protection : Device Protection per DoS Protection Profile: Security ›› DoS Protection : Protection Profiles .. select the specific profile Reference: K000141430: Configuring BIG-IP AFM DoS Protection Threshold Sensitivity https://my.f5.com/manage/s/article/K000141430 Scenario: DNS DDoS attack on F5 DNS listener Virtual Server Recommendations: BIG-IP AFM have DNS Attack types to detect and mitigate DNS DDoS attacks. If your BIG-IP does not have BIG-IP AFM licensed, it would be beneficial for the DNS service processed thru the F5 DNS listener VS to have mitigation options available from the DNS Attack types in the AFM DoS device or DNS enabled protection profile. Configure thresholds as per your needs. Here is a sample configuration from a lab device where DNS A Query Attack type in Device Protection is configured in Mitigate state and Fully Manual detection and mitigation thresholds. Bad Actor Detection can also be configured with thresholds. It is also possible to configure it for Fully Automatic threshold and will be dependent on the Threshold Sensitivity configuration. Scenario: DDoS attack on F5 Virtual Server and attacking IP addresses needs to be blocked Recommendations: BIG-IP AFM has Network Firewall Policy and rules where it can be configured to match a source address list and drop its traffic. This can also be done thru iRules, however, AFM firewall rule configuration is a native feature and is built for such operations. The F5 SIRT created a playbook for HTTP brute force mitigation and the LTM mitigation options includes such configurations should you decide to use iRules and BIG-IP LTM features. HTTP Brute Force Mitigation Playbook: BIG-IP LTM Mitigation Options for HTTP Brute Force Attacks - Chapter 3 HTTP Brute Force Mitigation Playbook: BIG-IP LTM Mitigation Options for HTTP Brute Force Attacks - Chapter 3 | DevCentral F5 also have K30534815: Attack mitigation matrix using F5 security products and services which lists existing F5 Support articles for attack mitigation. https://my.f5.com/manage/s/article/K30534815 During DDoS attacks, it is very likely that the some of the source IP addresses will have bad IP reputation, it will be beneficial to have IP Intelligence license available and use it in BIG-IP LTM (iRules and LTM Policy), AFM (IP Intelligence Policy) and ASM/Adv WAF (Security Policy) configurations. Refer to the following links on sample iRule configurations. https://clouddocs.f5.com/api/irules/IP__reputation.html https://clouddocs.f5.com/api/irules/IP__intelligence.html Note that the IP intelligence feature requires an add-on license. Contact your F5 or Partner salesperson for details on ordering the license. Scenario: BIG-IP device is suspected to be compromised. Recommendations: BIG-IP can be affected by malware and it finds it's way to it by exposing the BIG-IP management and self (self-IP) IP addresses and configured with insecure or easy to guess BIG-IP user password. BIG-IP product had previous Critical CVEs where authentication was not needed to exploit the vulnerability. F5 has the article K11438344: Considerations and guidance when you suspect a security compromise on a BIG-IP system to provide guidance on handling suspected compromised BIG-IP devices. https://my.f5.com/manage/s/article/K11438344 To minimize the attack surface of a BIG-IP device against CVEs and unauthorized access, ensure that only trusted authenticated users and networks have access to the BIG-IP management and self (self-IP) IP addresses and the BIG-IP device is running the latest BIG-IP software version. Do review the "Major Release and Long-Term Stability Release versions supported with active software development" of K5903: BIG-IP software support policy as it notes BIG-IP 15.1.x version reaches "End of Technical Support" this December 31, 2024. Note: For BIG-IP Next (BIG-IP 20.x and later), refer to BIG-IP Next software support policy. Major Release and Long-Term Stability Release versions First customer ship End of Software Development End of Technical Support Latest maintenance release 17.1.x March 14, 2023 March 31, 2027 March 31, 2027 17.1.1 16.1.x July 7, 2021 July 31, 2025 July 31, 2025 16.1.5 15.1.x December 11, 2019 December 31, 2024 December 31, 2024 15.1.10 K5903: BIG-IP software support policy https://my.f5.com/manage/s/article/K5903 F5 Distributed Cloud "F5 Distributed Cloud Services are SaaS-based security, networking, and application management services that enable customers to deploy, secure, and operate their applications in a cloud-native environment wherever needed–data center, multi-cloud, or the network or enterprise edge." https://www.f5.com/products/distributed-cloud-services F5 Distributed Cloud have many mitigation options for DDoS attacks. Volumetric DDoS can be handled by F5 Distributed Cloud DDoS Mitigation Service. F5 Distributed Cloud Bot Defense mitigates complex bot attacks. It provides integration option with your mobile application so it can be properly classified and detected as a trusted client. see Making Mobile SDK Integration Ridiculously Easy with F5 XC Mobile SDK Integrator https://www.f5.com/products/distributed-cloud-services/bot-defense https://www.f5.com/products/distributed-cloud-services/l3-and-l7-ddos-attack-mitigation Conclusion The Cyber Security Attack Scenarios and recommendations using BIG-IP features shared are not exhaustive. There are more complex environments and scenarios that BIG-IP deployments may have opportunity to mitigate network and application attack traffic and it is important that the appropriate BIG-IP licenses are available so the relevant modules can be provisioned and related features and configuration can be enabled. This will help your environment's network and application traffic to be resilient against DDoS attacks when BIG-IP is properly licensed, positioned and configured. I hope the sample configuration, logs and configuration help details have been useful and helpful as you consider the BIG-IP features mitigation options and improve your network, application and BIG-IP device security posture. Until next time! The F5 SIRT creates security-related content posted here in DevCentral, sharing the team’s security mindset and knowledge. Feel free to view the articles that are tagged with the following: F5 SIRT series-F5SIRT-this-week-in-security TWIS
