HTTP/2 DDoS Mitigation for SMB Web Servers and Hosting

There is a special kind of humility that arrives when you learn a single laptop on a residential cable connection can knock your company website offline faster than you can find the hosting login. Not a botnet. Not a nation state. One machine, one TCP connection, and a protocol feature that was designed to make the web faster. HTTP/2 DDoS mitigation used to be a problem for the Googles and Cloudflares of the world, and for most small and mid-sized businesses it quietly stopped being somebody else's problem around the time HTTP/2 became the default setting on every web server they own.

This week makes the point better than any whitepaper could. On November 11 the Apache Software Foundation shipped httpd 2.4.71 to fix CVE-2026-119618, a critical concurrency bug in mod_http2 that can turn heap corruption into unauthenticated remote code execution on versions 2.4.55 through 2.4.70. That one is a patch-now problem, full stop. But it is also the third serious Apache HTTP/2 advisory of 2026, following the CVE-2026-23918 double free in May and the cross-stack HTTP/2 Bomb in June that let one client flatten NGINX, Apache, IIS, Envoy and Cloudflare Pingora. When the same protocol layer keeps showing up in the advisory feed, the right response is not to keep patching and hoping. It is to build a hosting strategy that assumes the next HTTP/2 availability bug is already on its way.

Why HTTP/2 changed the economics of denial of service

The old mental model of a DDoS attack is a firehose. Somebody rents a botnet, points a few hundred gigabits at your IP address, and your upstream link drowns. That model still exists, and MITRE ATT&CK tracks it as T1498, network denial of service. It is expensive for the attacker and loud for everyone involved, which is why most small businesses rarely see it.

HTTP/2 introduced a different class of problem, the one ATT&CK files under T1499 as endpoint denial of service, specifically the service exhaustion and application exhaustion sub-techniques. HTTP/2 multiplexes many streams over one connection, compresses headers with a shared dynamic table called HPACK, and lets each side manage flow control windows that decide how fast data moves. Every one of those features asks the server to hold state on behalf of a client it has never met. Every piece of held state is a lever. The attacker's job is to find the lever where one cheap byte on the wire costs the server something expensive in memory or CPU.

The research history reads like a decade of people finding new levers. Imperva's 2016 analysis of HTTP/2 implementations described the original HPACK bomb, where a tiny header reference decompresses into a huge allocation. In October 2023, Google, Cloudflare and AWS jointly disclosed HTTP/2 Rapid Reset (CVE-2023-44487), in which clients open streams and immediately cancel them, forcing the server to do setup and teardown work at a pace the concurrency limits never anticipated. Google reported a peak of 398 million requests per second, Cloudflare saw 201 million from a botnet of roughly 20,000 machines, and CISA issued its own alert the same day. In April 2024 researcher Bartek Nowotarski published the CONTINUATION flood family (tracked by CERT/CC as VU#421644, with CVE-2024-27316 for Apache), which abused endless header continuation frames to exhaust memory on servers that buffered them before checking limits. In August 2025 the MadeYouReset technique (CVE-2025-8671) found a way to make the server itself issue the resets that the Rapid Reset patches were designed to count.

The June 2026 HTTP/2 Bomb (CVE-2026-49975 for Apache, with assignments for other stacks) is the composition of two old ideas. An attacker seeds the HPACK dynamic table with one header, then emits thousands of one byte references to it, each of which costs the server anywhere from about 70 bytes on NGINX and IIS to about 4,000 bytes on Apache httpd and Envoy. Then the attacker sets a zero byte flow control window so the server can never finish the response and free the memory, and sends just enough WINDOW_UPDATE frames to keep the connection from timing out. The researchers measured 32 gigabytes of server memory exhausted in under twenty seconds from a 100 Mbps home connection. That is not a volumetric attack. That is a lock pick.

The SMB hosting reality that makes this worse

Here is the thing about small business web hosting. It is almost never one server. It is a marketing site on a managed WordPress host, a customer portal on a virtual machine somebody built in 2021, an Exchange or IIS front end that never quite got retired, a reverse proxy in front of a line of business app, and maybe a vendor appliance with a web admin page. Each of those speaks HTTP/2 because the installer, the hosting control panel or a tuning guide turned it on. Very few of them were turned on by a person who thought about whether they needed to be.

That matters because an HTTP/2 availability attack is an origin attack. If the client can open an HTTP/2 connection directly to your server, the cost asymmetry lands on your memory and your CPU. If something in front of you terminates HTTP/2 first, the cost lands on that something, which is ideally a provider with a lot more memory than you have and an engineering team paid to care. The difference between those two architectures is the difference between reading about an advisory and living through it.

The second complication is that availability problems on small infrastructure rarely look like security incidents. A web server that runs out of memory gets restarted by the hosting panel, or by systemd, or by a technician who assumes it was a bad plugin. The logs, if they survived, show a burst of connections that completed nothing. Nobody files that as an incident. They file it as "the site was slow on Tuesday." Meanwhile the same mod_http2 code path that just fell over under memory pressure is the code path this week's CVE-2026-119618 says can be driven to code execution. Availability and integrity bugs in the same parser tend to travel together, which is why I treat the HTTP/2 layer as attack surface rather than plumbing.

Threat modeling HTTP/2 DDoS mitigation as a control objective

From a CISSP perspective the control objective is already written down for you. NIST SP 800-53 SC-5, denial of service protection, asks the organization to protect against or limit the effects of defined denial of service event types, and its enhancements cover restricting the ability of internal users to launch attacks and managing capacity so the system survives a flood (SC-5(2)). The trick is that word "defined." Most SMB risk registers have a single line that says "DDoS" with a mitigation of "hosting provider handles it." That line does not survive contact with an attack that requires no bandwidth at all.

A useful threat model splits the problem into three attacker profiles. The first is the opportunistic researcher clone, someone who downloads a public proof of concept the week after disclosure and points it at anything that answers on port 443 with an h2 ALPN response. This is the profile that matters most to small businesses because public HTTP/2 bomb and Rapid Reset tooling has existed for years and scanning for ALPN support is trivial. The second is the extortion crew, which uses a short demonstration outage to back up a ransom note, a pattern CISA, the FBI and MS-ISAC describe in their joint guide on understanding and responding to distributed denial of service attacks. The third is the distraction play, where a noisy outage on the public site absorbs the attention of a small IT team while something quieter happens on the VPN or the mail gateway.

Each profile maps to a different kind of evidence. Against the opportunistic clone, you need to know which of your hosts actually negotiate HTTP/2 and on which software versions. Against extortion, you need a pre-agreed decision about who is allowed to flip traffic to a protective provider, and how fast. Against the distraction play, you need monitoring that keeps watching the rest of the environment when the website is on fire. OWASP's API Security Top 10 makes a related point under API4:2023, unrestricted resource consumption, which is worth reading if your customer portal exposes an API over the same listener. Resource limits are a security control, not a performance setting.

Building an HTTP/2 inventory before the next advisory lands

You cannot rate the exposure of servers you do not know speak HTTP/2, so the first concrete step is an inventory, and it is less work than it sounds. For every public hostname in your DNS zone, check whether the server negotiates HTTP/2 and record the software and version answering. A quick check from any machine with a modern curl looks like this.

curl -s -o /dev/null -w '%{http_version}\n' --http2 https://www.example.com

A result of 2 means HTTP/2 was negotiated. Repeat it against the IP address of the origin as well as the hostname, because the interesting answer is often that the CDN speaks HTTP/2 to the world and the origin also speaks HTTP/2 to anyone who skips the CDN. On Apache hosts, running apachectl -M and looking for http2_module tells you whether the module is loaded at all, and the Protocols directive tells you whether it is actually offered. On NGINX the http2 parameter on the listen directive, or the newer standalone http2 directive, does the same job.

Record the result as a configuration management fact under CM-8, not as tribal knowledge in a technician's head. The inventory should answer four questions for each host. Does it negotiate HTTP/2 to the internet. Is it reachable directly or only through a proxy. What software and version terminates the HTTP/2 connection. Who owns patching it. When CVE-2026-119618 dropped on Tuesday, the businesses that had that list were done triaging before lunch. Everyone else spent the afternoon logging into hosting panels.

Then make the uncomfortable decision about whether each host needs HTTP/2 at all. An internal admin interface, a vendor appliance web page or a legacy portal with a dozen users gets essentially no benefit from multiplexed streams. Turning HTTP/2 off on those hosts removes the entire mod_http2 attack surface, and it is the only mitigation that also covers the next bug in that module, the one nobody has found yet. The intel writeup on this week's Apache fix noted that the standalone mod_h2 build from GitHub was archived in June with no fixed release, and for anyone running that build, disabling HTTP/2 or moving to the bundled module is the only option on the table.

Hardening the hosts that keep HTTP/2 turned on

For the public sites that genuinely benefit from HTTP/2, the strategy has two layers, and the outer layer matters more than the inner one.

The outer layer is to stop exposing the origin. Put the site behind a CDN or reverse proxy service that terminates HTTP/2 at its own edge, and then lock the origin firewall so it only accepts connections from that provider's published address ranges. That last part is the step most small businesses skip. A CDN in front of a server that still answers directly on its own public IP is a decoration, because the attacker who reads your DNS history or scans the provider's IP space will go around it. The big providers absorbed Rapid Reset precisely because they had engineering teams patching their edge within hours of disclosure. Your origin, sitting behind a properly enforced allowlist, never saw those frames. This is SC-7 boundary protection doing the work that SC-5 on its own cannot. I covered the same logic for application delivery controllers in our post on load balancer security, and the lesson carries over directly. Reachability is the control that works even before the patch exists.

If a provider can talk HTTP/1.1 to your origin, consider letting it. Plenty of CDNs default to HTTP/1.1 on the origin connection anyway, which means the HTTP/2 parsing that keeps generating advisories never touches your server. You lose very little performance on a typical business site and you remove a protocol stack from your patching burden.

The inner layer is tuning the server so a single connection cannot consume an unreasonable share of it. On Apache that means looking at H2MaxSessionStreams, H2WindowSize, LimitRequestFields, LimitRequestFieldSize and the Timeout and KeepAliveTimeout values, and keeping them close to defaults rather than the inflated numbers some performance guides recommend. On NGINX it means sensible values for keepalive_requests, keepalive_timeout, large_client_header_buffers and the per-connection stream concurrency. Pair those with a memory ceiling on the service itself, through systemd MemoryMax or container limits, so an exhausted worker gets killed and restarted rather than dragging the entire host and its database into swap. None of this stops a novel attack like the HTTP/2 Bomb on its own, because the whole point of that research was that existing limits were measured in the wrong unit. What tuning buys you is a smaller blast radius and faster recovery while the vendor patch is in flight.

Patching is still the floor. Give HTTP/2 stack updates a written clock under SI-2. CISA's Binding Operational Directive 22-01 sets federal agencies a deadline for anything on the Known Exploited Vulnerabilities catalog, and borrowing that clock for your internet-facing web servers is a reasonable, defensible choice for a business that does not have its own policy yet. Verify by asking the server what it is running after the update, not by trusting the package manager's success message, because restarts that never happened are a classic way to stay vulnerable with a clean ticket.

Detecting HTTP/2 abuse with a Managed SOC

Detection for HTTP/2 availability attacks is less about signatures and more about shape. The tell for Rapid Reset is a ratio of stream resets to completed requests that no real browser produces. The tell for CONTINUATION floods and HPACK bombs is a connection that sends a lot of header frames and never finishes a request. The tell for the slow-hold half of the HTTP/2 Bomb is a connection with a tiny or zero flow control window that stays open for minutes while sending only window updates. Most reverse proxies and CDNs can log stream counts, reset counts and connection duration, and a Managed SOC can alert on those ratios long before the memory graph goes vertical.

On the host side, the useful telemetry is boring. Memory pressure on the web tier, worker process restarts, out of memory kills in the kernel log, and a sudden drop in successful responses while connection counts stay flat. Forward those to a log platform the web server cannot write to, under AU-9, because a host that is out of memory does a poor job of keeping its own logs. And alert on absence. A web server that stops sending logs during a period when the CDN shows traffic hitting it is telling you something.

The final piece is correlation. Because availability attacks are sometimes cover for quieter work, the SOC should treat a public-site outage as a reason to look harder at identity and remote access, not a reason to stop looking. A spike of failed VPN logins or new mailbox rules during a web outage is exactly the kind of coincidence that deserves a human. NIST's incident handling guide, SP 800-61, frames denial of service as an incident category with its own containment strategy, and the first containment decision for most SMBs is simply who calls the CDN and how fast.

Write that decision down before you need it. Who has the credentials to put the site into the provider's under-attack mode. Who approves pulling the origin off the public internet entirely. Which vendor contract covers emergency onboarding if the site is not behind a protective provider today. Those three answers belong in the contingency plan under CP-2, and tabletop testing them once a year costs an hour and saves a very bad afternoon.

HTTP/2 DDoS mitigation as a hosting strategy, not a patch cycle

The pattern across a decade of HTTP/2 research is consistent. Every feature that makes the protocol efficient for honest clients makes it cheap for dishonest ones, and every round of fixes moves the cheapest lever somewhere new. Rapid Reset was patched, and MadeYouReset found a way around the counters. HPACK bombs were patched, and the HTTP/2 Bomb combined them with flow control. This week's Apache RCE is a reminder that the same parsing code can fail in ways that are worse than an outage.

So the durable answer to HTTP/2 DDoS mitigation for a small business is architectural. Know which hosts speak HTTP/2, turn it off where it buys nothing, keep the origin unreachable except through a provider that can absorb protocol-level abuse, tune limits so one connection cannot eat a server, patch on a written clock, and watch the shape of connections rather than waiting for a signature. None of it is exotic. All of it is the kind of work that slides when the website appears to be fine.

That is the work the Managed SOC and Threat Management module in CyberSphere is designed to carry. It watches the telemetry that catches protocol abuse early, from reset ratios and stalled connections at the edge to memory pressure and missing logs on the origin, and it ties each detection to a remediation ticket in the same platform, so the hostname that answered HTTP/2 directly last month shows up as an owned task rather than a surprise. It runs around the clock with dark-web breach monitoring on top, which matters when an outage is a smokescreen for something else, and MSP partners can deliver it under their own brand through the white-label portal. You can see the platform on our CyberOne page. Run that curl check against your own origin IPs this week. If any of them answer with a 2 to a stranger, you already know what the next item on the list should be.

Frequently Asked Questions

How quickly does Innovation Network Design respond to a security incident?

Our SOC triages and notifies within 15 minutes with confirmed details and containment steps, rather than handing you a queued alert. Incident response retainer clients carry a 2-hour guaranteed response.

Do you only work with businesses in the Dallas-Fort Worth area?

We are based in McKinney, Texas and work on-site across Plano, Allen, Frisco and the wider DFW metroplex. Our monitoring and response operate remotely, so we also support organizations nationwide.

How do we get started?

Start with a free assessment. Contact us or call 512-518-4408 and we will review your current setup and give you clear, prioritized recommendations before you commit to anything.