HTTP/2 Bomb Remote DoS Exploit Threatens Major Web Servers

A newly disclosed remote denial-of-service technique called HTTP/2 Bomb is raising serious concerns for organizations running modern web infrastructure.

The attack targets default HTTP/2 configurations across some of the world’s most widely deployed web servers, including nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora.

The issue is especially concerning because a single attacker using a normal home internet connection may be able to exhaust tens of gigabytes of server memory in seconds.

For enterprises, this is not just a web server performance problem.

It is a resilience, availability, and infrastructure security issue.

When web servers, proxies, gateways, and edge services become vulnerable to low-cost memory exhaustion attacks, business operations can be disrupted quickly.

What Happened:

Security researchers disclosed HTTP/2 Bomb, a remote denial-of-service exploit that abuses how some HTTP/2 implementations handle header compression and flow control.

The technique combines two older attack ideas in a more damaging way.

The first is an HPACK compression bomb.

The second is a Slowloris-style connection hold.

Individually, these concepts have been known in the security community for years.

The danger comes from how they are chained together.

The attack can force a server to allocate large amounts of memory while allowing the attacker to send very little data over the wire.

The result is a severe amplification effect where the attacker spends minimal bandwidth but forces the server to consume large amounts of memory.

Why This Issue Is Critical:

HTTP/2 is widely deployed across modern web infrastructure.

It is used by public websites, APIs, reverse proxies, cloud gateways, load balancers, CDNs, application platforms, and internal services.

That broad adoption makes HTTP/2-related denial-of-service risks especially important.

A memory exhaustion attack against a web server can degrade performance, crash workers, trigger out-of-memory conditions, disrupt application availability, or force infrastructure into swap.

For businesses that depend on customer portals, APIs, SaaS platforms, e-commerce systems, authentication gateways, or partner integrations, service degradation can quickly become a business continuity event.

The issue is also critical because it affects multiple major server technologies.

This is not limited to one vendor or one implementation.

The report identifies nginx, Apache httpd, Microsoft IIS, Envoy, and Cloudflare Pingora as affected targets.

Affected Web Server Technologies:

HTTP/2 Bomb has been demonstrated against several widely used server and proxy technologies.

• nginx
• Apache httpd
• Microsoft IIS
• Envoy
• Cloudflare Pingora

These technologies often sit directly in front of production applications.

They may act as public web servers, reverse proxies, API gateways, service mesh components, edge proxies, or load-balancing infrastructure.

That placement makes them highly valuable targets for attackers seeking disruption.

How the Exploit Works:

HTTP/2 Bomb abuses the relationship between HPACK compression and HTTP/2 flow control.

HPACK is HTTP/2’s stateful header compression mechanism.

It allows a sender to insert a header once and then reference it repeatedly using a small indexed value.

That design improves efficiency during normal traffic.

However, in this attack, the client seeds the dynamic header table with a value and then sends thousands of tiny indexed references.

The attacker pays very little bandwidth cost.

The server must expand, copy, process, and allocate memory for the referenced headers.

The second part of the attack abuses HTTP/2 per-stream flow control.

The attacker advertises a zero-byte flow-control window.

That prevents the server from completing its response.

The attacker then sends small WINDOW_UPDATE frames to keep the connection alive and prevent timeout.

This turns a temporary memory spike into a persistent memory hold.

How the Attack Chain Could Work:

A realistic HTTP/2 Bomb attack may follow this pattern.

• Attackers identify public-facing services that support HTTP/2
• The attacker opens a connection to the target server
• HPACK header compression is abused to create a high amplification ratio
• Thousands of indexed header references are sent with minimal bandwidth cost
• The server expands those references into much larger memory allocations
• Flow-control behavior is abused to prevent the response from completing
• Small WINDOW_UPDATE frames keep the connection active
• Memory remains pinned until the server slows, crashes, or becomes unavailable

This attack is dangerous because it does not require massive botnet traffic to create meaningful disruption.

The attacker’s cost can remain low while the defender’s resource consumption becomes very high.

Amplification and Memory Exhaustion Risk:

The reported amplification levels vary by implementation.

Some servers showed lower but still meaningful amplification.

Others showed extremely high memory growth under attack conditions.

The report describes memory exhaustion reaching tens of gigabytes within seconds or minutes depending on the target server.

This matters because memory exhaustion can affect more than the web server process itself.

It can destabilize the host, affect neighboring services, trigger container restarts, cause swap pressure, degrade application response times, and create cascading availability failures.

In containerized environments, memory limits may help contain the blast radius.

However, repeated worker crashes or container restarts can still disrupt service availability.

Why This Incident Matters for Cybersecurity:

HTTP/2 Bomb highlights an uncomfortable reality about modern protocol complexity.

Security weaknesses do not always come from a simple software bug.

Sometimes they emerge from the interaction between legitimate protocol features.

HPACK compression is useful.

HTTP/2 flow control is useful.

Persistent connections are useful.

But when these features are combined in a hostile way, they can create severe resource exhaustion conditions.

This is why protocol-aware testing matters.

A web service may pass traditional vulnerability scans and still be exposed to application-layer denial-of-service attacks.

Security teams must evaluate how infrastructure behaves under abnormal but standards-compliant traffic patterns.

Common Risks Highlighted:

This issue highlights several common enterprise weaknesses.

• HTTP/2 enabled by default without abuse testing
• Public-facing web servers with weak resource limits
• Reverse proxies exposed to direct internet traffic
• Incomplete visibility into HTTP/2 usage
• Limited monitoring of memory growth per connection
• Lack of hard per-request header count limits
• Insufficient rate limiting at the edge
• Weak protection against slow connection abuse
• Overreliance on default web server configurations
• Limited denial-of-service testing in security assessments

These weaknesses can allow low-bandwidth attacks to create outsized operational impact.

Potential Impact:

The potential impact of HTTP/2 Bomb can be serious for internet-facing organizations.

• Remote denial of service
• Memory exhaustion
• Worker process crashes
• Application downtime
• API disruption
• Gateway instability
• Reverse proxy degradation
• Increased cloud or infrastructure costs
• Service-level agreement failures
• Customer-facing outages
• Cascading failures across dependent services

For organizations that rely on web availability, even short disruptions can affect revenue, customer trust, operational continuity, and incident response workload.

What Organisations Should Do Now:

Organizations should review HTTP/2 exposure immediately.

• Identify all internet-facing systems that support HTTP/2
• Review nginx, Apache httpd, IIS, Envoy, and Pingora deployments
• Upgrade nginx to version 1.29.8 or later where applicable
• Apply available Apache httpd mod_http2 updates where applicable
• Disable HTTP/2 temporarily where patching or mitigation is not available
• Enforce hard per-request header count limits at the edge
• Apply memory limits using cgroups, ulimit, or container controls
• Review reverse proxy and CDN protections
• Monitor for abnormal HTTP/2 connection behavior
• Test how production-like systems respond to resource exhaustion attempts
• Document temporary mitigations and track permanent fixes

Disabling HTTP/2 may affect performance and user experience, but it can be a practical temporary control when exposure is high and patching is not immediately available.

Detection and Monitoring Strategies:

Defenders should monitor HTTP/2 behavior closely.

• Track unusual HTTP/2 connection duration
• Monitor high memory usage tied to specific client connections
• Detect abnormal WINDOW_UPDATE frame patterns
• Watch for large numbers of repeated header references
• Monitor sudden worker memory growth
• Review proxy and web server error logs
• Detect repeated out-of-memory events
• Watch for increased swap usage
• Monitor container restarts linked to web servers or proxies
• Correlate traffic spikes with memory exhaustion events

Traditional volumetric DDoS monitoring may not be enough.

HTTP/2 Bomb is dangerous because it can create high server-side resource consumption without requiring massive inbound bandwidth.

The Role of Incident Response Planning:

Incident response teams should prepare for application-layer denial-of-service scenarios.

An HTTP/2 Bomb attack may look different from a traditional bandwidth flood.

Network traffic volume may appear modest while server memory usage rises quickly.

This can delay diagnosis if teams only look at inbound traffic volume.

Response plans should include rapid HTTP/2 disablement procedures, reverse proxy rule changes, emergency edge configuration updates, traffic capture workflows, and escalation paths for infrastructure owners.

Teams should also know how to preserve evidence while restoring availability.

During a live availability incident, speed matters.

But after containment, defenders should review logs, traffic patterns, source distribution, and infrastructure behavior to improve future resilience.

Penetration Testing Insight:

From a penetration testing perspective, HTTP/2 Bomb is a reminder that web infrastructure testing must include protocol-layer resilience.

Many organizations test applications for injection, authentication, authorization, and misconfiguration issues.

Fewer organizations test how web infrastructure behaves under hostile protocol usage.

A strong assessment should validate whether HTTP/2 services can resist low-bandwidth resource exhaustion attempts.

• Inventory HTTP/2-enabled services
• Test web server and proxy resource limits
• Validate header count and decoded header size controls
• Assess timeout behavior for slow or stalled streams
• Review memory limits on workers and containers
• Evaluate CDN and reverse proxy protections
• Simulate controlled application-layer denial-of-service conditions
• Validate alerting for abnormal HTTP/2 traffic patterns
• Confirm emergency rollback or HTTP/2 disablement procedures
• Test whether service degradation cascades into dependent systems

Modern penetration testing should not only ask whether an application can be hacked.

It should also ask whether the application can remain available under realistic abuse conditions.

Expert Insight:

James Knight, Senior Principal at Digital Warfare, said:

“Application-layer denial-of-service attacks are dangerous because they often exploit normal protocol behavior rather than obvious malware or brute force traffic. HTTP/2 Bomb shows why enterprises need to validate resilience, not just patch vulnerabilities.”

What Security Leaders Should Prioritize:

Security leaders should treat this issue as a test of web infrastructure resilience.

The key question is not only whether HTTP/2 is enabled.

The real question is whether the organization understands where it is enabled, how it is protected, and how quickly it can be restricted during an active availability incident.

Leaders should prioritize exposure visibility, configuration governance, protocol-aware monitoring, and incident response readiness.

If teams cannot quickly identify HTTP/2-enabled assets, apply emergency configuration changes, or detect abnormal memory exhaustion patterns, the organization has a resilience gap.

Call to Action:

Organizations should not assume default HTTP/2 configurations are safe against modern denial-of-service techniques.

Validate exposure, test web server resilience, review reverse proxy protections, and confirm that a low-bandwidth attacker cannot exhaust enterprise web infrastructure.

Contact Digital Warfare to schedule a security consultation and assess whether your web servers, APIs, proxies, and edge systems can withstand HTTP/2 Bomb-style resource exhaustion attacks.