How to Handle the HTTP/2 Bomb Vulnerability: Impact and Mitigation for CVE-2026-49975

HTTP/2 Bomb is a recently disclosed HTTP/2 denial-of-service risk. It is related to CVE-2026-49975, and the core issue is that an attacker can send small requests that cause a server to allocate and hold large amounts of memory, eventually slowing the service, pushing it into swap, or making it unavailable.

This is easy to mistake for “just another DDoS.” The danger is not high traffic volume. The danger is memory amplification: the client sends little data, while the server may pay a much larger resource cost when handling HTTP/2 header compression and flow-control state.

For operations and security teams, the first priority is not reproducing the attack. It is identifying where HTTP/2 terminates, then upgrading the relevant components or temporarily disabling HTTP/2.

Why It Is Dangerous

HTTP/2 Bomb combines two older classes of problems.

The first is HPACK-related compression amplification. HTTP/2 uses HPACK to compress headers. A client can use very short references that make the server reconstruct and allocate header structures. If an implementation does not sufficiently limit header-field counts, Cookie fragments, or internal bookkeeping overhead, the server may allocate a large amount of memory for a very small input.

The second is a Slowloris-like hold. The attacker can use HTTP/2 flow control so the server cannot complete its response normally, keeping the previously allocated memory pinned in the process for a long time.

Individually, neither idea is new. The problem is that when they are chained together, the attack does not need high bandwidth or necessarily a huge number of connections to push backend memory into a dangerous state.

Components to Check First

Public disclosure has mentioned the following HTTP/2 server implementations as affected or worth checking:

nginx
Apache httpd
Microsoft IIS
Envoy
Cloudflare Pingora

NVD currently describes CVE-2026-49975 in relation to Apache HTTP Server mod_http2, affecting Apache HTTP Server 2.4.17 through 2.4.67. Red Hat also categorizes the related issue as HTTP/2 HPACK denial of service and notes that httpd, nginx, Envoy, and other components need component-specific handling.

Two details matter here.

First, not every backend application service is directly exposed. Start by checking HTTP/2 termination points: public load balancers, reverse proxies, Ingress, gateways, CDN origin layers, API gateways, and service-mesh entry points.

Second, CVE assignment and vendor coverage are not identical across products. Do not assume that one CVE number covers every component you run. Check the actual HTTP/2 component against its vendor or distribution advisory.

Quick Self-Check

Start with this order:

Is HTTP/2 enabled on your public entry points?
Where does HTTP/2 terminate: CDN, WAF, load balancer, Nginx, Apache, Envoy, IIS, or service mesh?
Is the terminating component version within the vendor-fixed range?
Can an upstream proxy limit header-field counts, Cookie fragments, connection lifetime, and per-worker memory?
Is there any path that bypasses CDN/WAF and connects directly to the origin?

Many sites appear to sit behind a CDN, but origin IPs, backup domains, test domains, admin entries, or canary entries may still expose HTTP/2 directly. What matters is every boundary that can accept HTTP/2, not just the main website domain.

Fixes and Mitigations

Upgrading should be the first choice.

For nginx, public disclosure mentions that 1.29.8+ introduced relevant limits. If you cannot upgrade, consider temporarily disabling HTTP/2.

For Apache httpd, track the fixed mod_http2 version. Public sources mention mod_http2 v2.0.41 as containing a fix. Red Hat’s temporary mitigation is to make affected virtual hosts use only HTTP/1.1:

1

Protocols http/1.1

For nginx, a temporary mitigation may be to disable HTTP/2 according to vendor or distribution guidance:

1

http2 off;

For Envoy, IIS, Pingora, or managed gateways, follow the relevant vendor advisory. Do not blindly apply Nginx or Apache configuration assumptions, because the vulnerable limit and fix may differ.

For systems that cannot be upgraded immediately, consider these defensive controls:

Limit request header-field counts at the edge, including split cookie fields;
Limit abnormally long-lived HTTP/2 streams;
Set limits for HTTP/2 connections, concurrent streams, request rate, and memory;
Set reasonable memory limits for workers or containers so one process does not drag down the whole host;
Ensure origins accept traffic only from trusted proxies, preventing WAF/CDN bypass;
Monitor HTTP/2 connection counts, active streams, memory spikes, swap usage, and 5xx errors.

These controls do not replace patches, but they can reduce exposure during the patch window.

Higher-Risk Scenarios

Risk is higher in environments such as:

Publicly exposed Nginx / Apache / Envoy / IIS with HTTP/2 enabled;
API gateways or Ingress layers with HTTP/2 enabled;
Origins that can be reached directly around the CDN;
Small-memory hosts serving multiple sites or services;
No worker or container memory limits;
No monitoring for abnormal connections, streams, or memory growth;
Availability-sensitive services without a quick HTTP/1.1 rollback plan.

Even internal-only services should not ignore this. Internal misuse, test scripts, exposed supply-chain components, or service-mesh entry misconfiguration can turn a public-facing issue into an internal availability problem.

Do Not Focus Only on CVSS

Scores around this issue can be confusing. Some sources emphasize CVSS 9.8, while the NVD page currently shows a CISA-ADP CVSS 3.1 score of 7.5 High, and NVD’s own assessment is still being enriched.

For real defense, the score is not the first decision point. Better questions are:

Is your HTTP/2 entry point affected?
Is it reachable from the internet?
Have you upgraded to a vendor-fixed version?
Can you quickly disable HTTP/2?
Do you have memory, connection, and stream-level protections?
Is there any path that bypasses front-end protection and reaches the origin?

If several of these answers are uncertain, treat it as high priority.

Suggested Operations Order

Proceed in this order:

List all HTTP/2 termination points;
Check vendor advisories for versions and fix status;
Upgrade public entry points and edge proxies first;
Temporarily disable HTTP/2 where upgrades are not yet possible;
Verify that origins accept only trusted proxy traffic;
Set memory boundaries for workers, containers, or service processes;
Add monitoring for HTTP/2 connections, streams, header-field counts, and memory anomalies;
After the change window, verify that business traffic still works normally.

Disabling HTTP/2 may affect performance, connection reuse, and some client behavior. But when patches are unavailable or exposure is unclear, it is a steadier temporary choice than leaving the edge unprotected.

Conclusion

The key risk in HTTP/2 Bomb is not “how much traffic” the attacker sends. It is that a small request can trigger large memory allocation and keep that memory held. That makes it especially dangerous for edge services with HTTP/2 enabled by default.

Do not start by trying to reproduce it, and do not rely on a single CVE page. First identify every HTTP/2 termination point, then confirm status component by component across Nginx, Apache, Envoy, IIS, Pingora, or your distribution. Upgrade where possible. Where you cannot upgrade, temporarily disable HTTP/2 and add header-field, connection, stream, and memory limits at the edge.

References: Calif original disclosure, NVD CVE-2026-49975, HAProxy analysis, Red Hat RHSB-2026-007