Skip to main content
gsharma
Staff
gsharma
Staff
June 11, 2026

Technical Tip: Blocking HTTP/2 Bomb attacks for CVE-2026-49975

  • June 11, 2026
  • 0 replies
  • 229 views

Description

This article describes the way to minimize the effect of CVE-2026-49975 through FortiWeb.

Scope

FortiWeb.

Solution

Here is some background about this vulnerability.
CVE-2026-49975, dubbed the HTTP/2 Bomb, is a critical remote Denial-of-Service(DoS) vulnerability affecting the default HTTP/2 configurations of major web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora.

Discovered by security firm Calif using OpenAI's Codex, it combines a unique HPACK compression-bomb variant with a Slowloris-style flow-control window hold to cause immediate server outages and memory exhaustion.

As a full reverse proxy, FortiWeb terminates HTTP/2 client connections and applies its own HTTP/2 limits and protocol constraints to client traffic, constraining the header-abuse component of the attack.

FortiWeb v7.6.9 strengthens this coverage with dedicated HTTP/2 controls: it extends the per-request header-line limit to HTTP/2 and adds a configurable minimum HTTP/2 Initial Window Size to constrain the flow-control hold.


The exploit combines two phases:

  1. Bookkeeping compression bomb (HPACK).
    Unlike traditional compression bombs that expand large stuffed strings to trip decoded-size limits, this variant uses a nearly empty header payload.
    The amplification comes from the per-entry bookkeeping and structural tables the server allocates around each header field, so the decoded-size limit never fires, because there is almost nothing to decode.
    Where a server caps the header-field count instead, the Cookie header can be split into many small fields to bypass the limit ( permitted by RFC 9113 8.2.3).

  2. Flow-Control Slowloris hold.
    With the internal memory overhead forced, the client advertises a zero-byte flow-control window, preventing the server from sending a response while it resets send timeouts. The connection stays active, trapping the allocated memory indefinitely.
    Because both vectors use standard, valid HTTP/2 frame properties, an unauthenticated attacker on a basic home computer over a 100 Mbps connection can exhaust up to 32GB of server memory in roughly 20 seconds, taking targeted infrastructure offline almost instantly. Proof-of-concept exploit code is publicly available.


Mitigation and Protection:
Organizations should audit their web-server footprint and apply vendor updates immediately:

  • NGINX: Fixed in version 1.29.8+ (adds a header-count limit, default 1000). If unable to upgrade, disable HTTP/2.

  • Apache HTTPD: Fixed in late-May releases (cookie fields now count against the request-field limit; mod_http2 update).

  • Microsoft IIS, Cloudflare Pingora: Default configurations are reported as exposed at the time of writing; monitor memory thresholds or temporarily disable HTTP/2 on unpatched public endpoints if no downstream mitigation is in place.

  • Envoy (CVE-2026-47774): Fixed in versions 1.35.11, 1.36.7, 1.37.3, and 1.38.1.

  • Perimeter protection and origin patching are complementary — apply both.


FortiWeb Protection:
FortiWeb sits in front of applications as a full reverse proxy. It does not pass HTTP/2frames straight through to the origin; rather, it terminates the client connection, inspects the traffic, and re-originates a clean connection to the back-end.
This lets FortiWeb apply its own HTTP/2 limits and protocol constraints to client traffic before it reaches the servers.

For this Vulnerability - HTTP/2 bomb CVE-2026-49975, some signatures will be available soon.

Recommended actions on FortiWeb:

  1. Upgrade to FortiWeb v7.6.9.
    Out of the box, the Number of Header Lines in Request constraint is enabled by default with an alert & deny action and is now enforced for HTTP/2 as well as HTTP/1.x, providing baseline protection against the header-abuse component of this attack with no additional configuration.

  2. HTTP protocol constraint Policy:

  • Navigate to Web Protection -> Protocol -> HTTP -> HTTP Protocol Constraints -> Create new.

  • Give a name and expand the HTTP/2 option below.

Tune the numbers for HTTP/2 max requests and Number of Concurrent Streams to as low as possible, based on the Application requirement, then set action Alert & Deny to block the requests and streams exceeding that number. HTTP/2 Max Requests caps the number of requests allowed over a single HTTP/2connection, limiting how far an attacker can push multiplexed malicious streams on one connection.

FortiWeb also enforces a built-in upper bound on the number of header lines a single request may carry, inherently limiting the dense header structures the HTTP/2Bomb depends on.

b60e3279.jpg


  1. DOS Protection.

  • Navigate to DOS Protection -> Network -> TCP flood prevention -> Create new.

  • Set the TCP Connection Number Limit and keep it as low as possible based on the application requirements, then set the action to Alert & Deny for exceeding numbers, then select OK.

  • Call this TCP Flood Prevention policy in the DOS protection Policy, then later assign this DOS Protection policy in the Web-Protection profile assigned for the concerned Server Policy.

3416557c.jpg


  1. Tune Server Policy.
    This config could help to slow down the traffic to the back-end to minimize the effect.

FortiWeb # config server-policy policy
FortiWeb (policy) # edit "CVE-2026-49975 - HTTP/2 Bomb"
FortiWeb (CVE-2026-49975~-) # set send-buffers-number 50
FortiWeb (CVE-2026-49975~-) # end
FortiWeb #


Note: The numbers above are only for reference and not a recommendation. Tune according to the application requirement; smaller is better, and Signatures will be added soon in future releases with the fix in the code.

  1. Vulnerability of FortiWeb itself to CVE-2026-49975.

FortiWeb is not one of the affected servers; as a reverse proxy, it terminates client connections and applies its own HTTP/2 limits and protocol constraints. These constrain the header-abuse component of the attack, and FortiWeb v7.6.9 adds dedicated HTTP/2controls (header-line enforcement and a minimum Initial Window Size) covering the flow-control component. Origin servers should still be patched.


  1. Action required.

After upgrading to FortiWeb v7.6.9, the Number of Header Lines in Request constraint is enabled by default with an alert & deny action and enforced on HTTP/2 traffic, giving baseline protection against the header-abuse component with no extra configuration. For deeper, application-specific protection, tune that limit along with the HTTP/2 Initial Window Size and HTTP/2 Max Requests on Web Protection policies. Continue to patch the origin servers.


  1. Patching back-end servers.

Perimeter protection and origin patching are complementary; apply both.

Terms & ConditionsAccessibility statement