What is the HTTP/2 Bomb and how FortiWeb 7.6 mitigates it
This article explains the HTTP/2 Bomb (CVE-2026-49975) and demonstrates how FortiWeb 7.6 reduces its risk for published services through HTTP Protocol Constraints, DoS Protection, Server Policy, and log monitoring.
خلاصه تخصصی مقاله
This article explains the HTTP/2 Bomb (CVE-2026-49975) and demonstrates how FortiWeb 7.6 reduces its risk for published services through HTTP Protocol Constraints, DoS Protection, Server Policy, and log monitoring.
موضوعات اصلی: پشتیبانی شبکه، HTTP، FortiWeb، Backend، Protection، Header
1. What is the HTTP/2 Bomb?
The HTTP/2 Bomb is a resource exhaustion attack that targets the handling of header compression, streams, and flow control in HTTP/2. Unlike traditional volumetric attacks, its goal is not necessarily to consume bandwidth but to force the server to allocate memory and internal structures for seemingly valid requests, and not release them quickly.
The attack has been described as combining an HPACK header compression abuse pattern with a Slowloris-style connection hold. The result can be high memory usage on the web server and service disruption.
This article is written for FortiWeb 7.6 and focuses on how FortiWeb as a WAF and reverse proxy can reduce the risk of this attack using HTTP Protocol Constraints, DoS Protection, proper Server Policy configuration, and log monitoring.
Note If your service is published behind FortiWeb, the key defensive point is to control abnormal HTTP/2 behavior at the WAF layer before requests reach the backend. FortiWeb is not only a signature-based WAF; it can also constrain abnormal HTTP/2 behavior through protocol constraints and health of HTTP/2.
2. Why is this attack dangerous?
The main risk of the HTTP/2 Bomb lies in the mismatch between attacker cost and server cost. An attacker can force the server to allocate much more memory for headers, streams, and internal structures with relatively little data on the wire. If memory is not freed promptly, the server may become occupied with keeping malicious connections rather than serving real users.
| Attack characteristic | Operational impact |
|---|---|
| Less bandwidth than volumetric DDoS | Can be significant with a single client or few clients. |
| Uses legitimate HTTP/2 behaviors | Detection is harder when looking at standard web payload alone. |
| Involves HPACK and Flow Control | Memory usage, latency increase, and service response disruption. |
| Affects well-known web servers | Risk for publicly exposed services with default HTTP/2 settings. |
3. Relation to HPACK and Flow Control
HTTP/2 uses HPACK to compress headers. HPACK allows both ends to reuse a dynamic table for header compression and references. While this improves performance, without proper limits on the header table, total headers, the number of streams, and frame sizes it can become a pressure point.
The other part of the attack targets Flow Control. A client can constrain server-sent responses by using a small or zero window size. If the server keeps resources reserved and the connection remains open, memory is not freed and pressure continues on the backend.
Warning This attack is not necessarily identifiable by a single URL, SQL injection, XSS, or classic payload. The detection point is the HTTP/2 protocol behavior; therefore controls like HTTP Protocol Constraints, Stream/Header limits, and memory monitoring are essential.
4. Where does FortiWeb fit in this scenario?
In an optimal setup, FortiWeb should sit in front of the backend as a reverse proxy. The client connects to FortiWeb, FortiWeb performs security checks, and forwards the request to the Server Pool. This allows FortiWeb to constrain abnormal HTTP/2 behaviors before they reach the web server.
Client → FortiWeb → Server Policy → Server Pool → Backend Web Server
If FortiWeb is used only in a limited fashion without an appropriate Web Protection Profile, it may simply publish the service and not enforce the defensive controls. For HTTP/2 Bomb, Server Policy should connect to a Web Protection Profile with properly configured HTTP Protocol Constraints and DoS Protection.
5. FortiWeb 7.6 approach to reducing risk
FortiWeb’s approach for this scenario is not a magic button; it requires layered controls. The most critical part is constraining HTTP/2 behavior via HTTP Protocol Constraints, alongside DoS Protection, rate limiting, log monitoring, and backend hardening.
| Defensive layer | FortiWeb capability | Effect on HTTP/2 Bomb risk |
|---|---|---|
| Protocol control | HTTP Protocol Constraints | Limits on Header Compression Table, Streams, Frame Size, and Header List Size. |
| Request volume and rate control | HTTP Access Limit / HTTP Flood / DoS Protection | Reduces pressure from high volumes or suspicious connections. |
| Propagation path control | Server Policy and Server Pool | Places FortiWeb before the backend to prevent harmful behavior from reaching the web server. |
| Protocol version control | Service and HTTP/HTTPS settings | Disable HTTP/2 where it is not required. |
| Monitoring | Attack Log, Traffic Log, Event Log, FortiAnalyzer | Detects anomalies, denials, resource consumption, or abnormal clients. |
Operational guidance In the first phase, enable these constraints on a test policy or a low-risk service with Action set to Alert. After reviewing Attack Logs and confirming no false positives, switch to Alert & Deny for sensitive services.
Starter configuration example
These values are not a universal standard, but can serve as a starting point for public-facing services during initial testing. If your header or cookie payload is heavy, assess real user behavior before applying Deny.
<| Item | Starting point | Explanation |
|---|---|---|
| Header Compression Table Size | 4096 to 8192 | Do not raise excessively to prevent HPACK abuse. |
| Number of Concurrent Streams | 50 to 100 | Lower for sensitive portals; test for high-traffic services. |
| Initial Window Size | Default or lower based on testing | Increasing this is not generally beneficial for security. |
| Frame Size | Default | Typically not necessary to increase. |
| Header List Size | 16384 to 65536 | Depends on header size in the application. |
| HTTP/2 Max Requests | 500 to 1000 | Set according to service longevity and load. |
7. DoS Protection and Rate Limiting in FortiWeb
HTTP Protocol Constraints are the main layer for HTTP/2 behavior control, but overall service pressure can be reduced with DoS Protection. DoS Protection can enforce HTTP Flood, HTTP Access Limit, TCP Flood, and policies for Malicious IP. These capabilities are not a replacement for patching HTTP/2, but can mitigate attack impact or similar behaviors.
DoS Protection → HTTP Flood
DoS Protection → HTTP Access Limit
DoS Protection → TCP Flood
DoS Protection → Exception Policy
Note For high-traffic services, DoS Protection should be configured with a real baseline. Determine natural request rates, connections, API behavior, allowed bots, and monitored IPs before setting thresholds.
8. Deployment scenarios
Scenario 1: Public service with nginx or Apache backend
FortiWeb should sit as a Reverse Proxy in front of the backend. Enable HTTP/2 on the client side only if needed. Patch the backend or disable HTTP/2 on the backend if patching is not available.
- Activate HTTP Protocol Constraints for HTTP/2.
- Limit Header Compression Table Size and Concurrent Streams.
- Set Action to Alert first, then Alert & Deny after validation.
- Patch the backend or disable HTTP/2 on the backend if needed.
Scenario 2: API Gateway with many headers and cookies
In APIs, overly strict reductions of Header List Size or Concurrent Streams may cause false positives. Use Traffic Log and Attack Log to identify real header patterns.
- Apply stricter limits on Login and Token Endpoints paths.
- For internal APIs with specific clients, consider IP Allow List or Client Certificate checks.
- For public APIs, enable Rate Limit and HTTP Access Limit.
Scenario 3: Systems that do not require HTTP/2
If your application works well with HTTP/1.1 and HTTP/2 offers no clear operational benefit, the simplest risk reduction is to disable HTTP/2 in the publish path. This is sensible for legacy services, internal systems, and applications with simple headers.
9. Checklist for review and implementation
| Item | Desired state |
|---|---|
| Identify HTTP/2-enabled services | All Server Policies with HTTP/2 enabled identified. |
| Patch backend | Backend like nginx, Apache, IIS, Envoy behind FortiWeb updated to a secure version. |
| HTTP Protocol Constraints | Appropriate HTTP/2 constraints enabled for sensitive Server Policies and attached to Web Protection Profiles. |
| Action | Start with Alert, then switch to Alert & Deny after false positives are ruled out. |
| DoS Protection | HTTP Flood and HTTP Access Limit set with a real service baseline. |
| Backend protocol | If HTTP/2 is not needed on the backend, ensure FortiWeb-backend communication uses HTTP/1.1. |
| Memory monitoring | Monitor memory usage and backend FortiWeb processes. |
| Logs and FortiAnalyzer | Attack Log, Traffic Log, and Event Log sent to FortiAnalyzer for searchability. |
10. Best Practice
- Enable HTTP/2 only for services that truly need it.
- Place FortiWeb in a reverse proxy path to control HTTP/2 behavior before the backend.
- Create separate HTTP Protocol Constraints for sensitive services and do not unify with general service profiles.
- Start with Alert for changes, then enable Deny after log review.
- Patching the backend remains essential; the WAF is a defensive layer, not a patch replacement.
- If the service sits behind a CDN or Load Balancer, verify which HTTP version is used from client to backend.
- For internal monitoring IPs, define exceptions only when needed and with tight limits.
برای ارزیابی پایداری، امنیت و نگهداری این زیرساخت، راهنمای پشتیبانی شبکه را نیز مطالعه کنید.