HTTP/2 Rapid Reset DDoS technique (CVE-2023-44487)

In August 2023, threat actors began quietly weaponizing a previously unknown weakness in the HTTP/2 protocol itself — not in any single vendor's code, but in how the protocol's stream multiplexing was designed to work. By the time Google, Cloudflare, and AWS jointly disclosed the issue on October 10, 2023 as CVE-2023-44487, "HTTP/2 Rapid Reset," it had already been used to generate the largest volumetric DDoS attacks ever recorded — Google alone mitigated a peak of 398 million requests per second, and Cloudflare reported floods exceeding 201 million rps, both roughly three times larger than any previously observed attack. Because the flaw lives in the HTTP/2 specification's handling of stream cancellation, it affected virtually every server, proxy, load balancer, and CDN that terminates HTTP/2 traffic, making this one of the most broadly impactful infrastructure vulnerabilities of 2023.

What the vulnerability actually does

HTTP/2 introduced multiplexing: a single TCP connection can carry many concurrent "streams," each representing an independent request/response exchange. To prevent resource exhaustion, servers cap the number of concurrent streams a client can have open at once (commonly 100). The protocol also allows either side to cancel an individual stream mid-flight with an RST_STREAM frame, which is a legitimate and common operation — browsers use it constantly to abandon requests a user navigated away from.

Rapid Reset abuses that legitimate mechanism. An attacker opens a stream by sending a request, then immediately sends RST_STREAM to cancel it before the server finishes processing — and repeats this cycle thousands of times per second on the same connection. Because each stream is opened and reset almost instantly, the server's concurrent-stream counter never reaches the limit that would normally throttle the client, even though the backend has already done real work: allocating stream state, parsing headers, and in many architectures, dispatching the request to an upstream application server or worker thread before the cancellation is processed. The attacker gets to force expensive server-side work per request while paying almost nothing themselves, and a single TCP connection — sometimes just a handful of connections — can generate request volumes that would otherwise require a massive botnet.

This is fundamentally a design-level flaw in the HTTP/2 stream lifecycle, not a memory-safety bug or logic error confined to one codebase. That's why the fix had to be implemented independently, and somewhat differently, across dozens of HTTP/2 implementations.

Affected versions and components

Because HTTP/2 stream cancellation is part of the core RFC 7540 protocol, the exposure list is unusually wide. Confirmed-vulnerable implementations prior to patching included:

• Web/application servers: nginx (pre-1.25.3), Apache HTTP Server (pre-2.4.58), Apache Tomcat, Eclipse Jetty, Microsoft IIS and the .NET/Kestrel HTTP/2 stack, Node.js's built-in HTTP/2 module
• Proxies and load balancers: Envoy, HAProxy, F5 BIG-IP, Netty-based gateways
• Language/runtime HTTP/2 libraries: Go's net/http, gRPC-core and its language bindings, Netty, Apple's swift-nio-http2
• Cloud and CDN edge infrastructure: AWS (ALB, CloudFront, API Gateway), Google Cloud load balancing, Cloudflare, Microsoft Azure Front Door, Akamai, Fastly

If your organization terminates HTTP/2 anywhere in its request path — at the CDN edge, at a cloud load balancer, at an API gateway, or directly on an application server — some component in that chain was almost certainly affected before October–November 2023 patch cycles. Environments running older, unpatched, or vendor-abandoned HTTP/2 stacks (self-managed proxies, embedded devices, legacy middleware) remain at risk today if they were never updated.

Severity, exploitation, and KEV status

NVD scores CVE-2023-44487 at CVSS 3.1 base score 7.5 (High) — AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — reflecting a network-exploitable, low-complexity, unauthenticated attack whose sole impact is availability. Several downstream advisories from affected vendors scored their specific implementations higher, up to the 8.x range, where request amplification against backend compute was especially severe.

This is not a theoretical finding. Because it was discovered as an active, in-the-wild attack technique rather than through research disclosure, CISA added CVE-2023-44487 to the Known Exploited Vulnerabilities (KEV) catalog at the time of disclosure, and its EPSS (Exploit Prediction Scoring System) probability has sat near the top of the scale ever since — consistent with a vulnerability that is trivial to weaponize, requires no authentication, and was already being used at internet scale before a patch existed. For any organization tracking KEV-driven remediation SLAs (as required under CISA Binding Operational Directive 22-01 for federal agencies, and adopted as best practice by many enterprise vulnerability management programs), this CVE should have been treated as a same-week priority, not a routine patch-cycle item.

Timeline

• August 2023: Attackers begin exploiting the technique in the wild against multiple large internet properties, generating record-breaking DDoS traffic. Google, Cloudflare, and AWS independently observe and begin mitigating the pattern.
• October 10, 2023: Coordinated public disclosure. Google, Cloudflare, and AWS publish joint technical writeups; CVE-2023-44487 is officially assigned and published.
• October 2023: CISA adds CVE-2023-44487 to the KEV catalog. Major vendors — nginx, Apache, Microsoft, F5, Envoy, Netty, gRPC, and others — release patched versions and mitigation guidance within days to weeks of disclosure.
• October–November 2023: Cloud providers roll out server-side mitigations transparently to customers on managed load balancers and CDNs (AWS, Google Cloud, Azure, Cloudflare, Fastly, Akamai).
• Late 2023 – ongoing: Security researchers and CDNs continue reporting sporadic Rapid Reset-style traffic against unpatched or self-managed edge infrastructure, underscoring that patch adoption for infrastructure-layer software lags well behind that of application code.

Remediation steps

1. Patch every HTTP/2-terminating component. Update web servers, reverse proxies, load balancers, and language HTTP/2 libraries to the vendor-specified fixed versions (e.g., nginx ≥1.25.3, Apache httpd ≥2.4.58, and the corresponding fixed releases for Envoy, HAProxy, Jetty, Tomcat, .NET, Node.js, and gRPC). Don't stop at the reverse proxy — check every hop, including internal service-to-service gRPC traffic.
2. Verify managed cloud and CDN mitigations are active. Most major cloud and CDN providers pushed fixes at the infrastructure layer, but confirm this explicitly for any self-managed ingress (Kubernetes ingress controllers, self-hosted API gateways) that sits behind or alongside managed services.
3. Add stream-reset rate limiting. Configure servers to close connections or apply penalties when a client resets an abnormal number of streams within a short window — this is the specific mitigation most vendor patches implement, and it should be tunable independent of the general request-rate limit.
4. Cap concurrent streams and connection counts defensively, and ensure request-processing work (auth, routing, upstream dispatch) is deferred until after cheap validation, so a canceled stream doesn't still trigger expensive backend work.
5. Instrument for detection. Monitor for spikes in RST_STREAM frame volume, unusually high request-to-response-completion cancellation ratios, and CPU/connection-table pressure that doesn't correlate with completed requests — these are the practical telltales of Rapid Reset traffic, patched or not.
6. Inventory before you assume you're covered. Because this vulnerability spans dozens of independent codebases, a single patched nginx front door does not guarantee protection if an internal gRPC service or a legacy proxy further downstream is still running a vulnerable version.

How Safeguard Helps

CVE-2023-44487 is a textbook case of why patch status alone doesn't tell you your risk: the vulnerable code is often several hops deep in vendored HTTP/2 libraries, proxy sidecars, and gRPC dependencies that most inventories miss. Safeguard's SBOM generation and ingest pipeline surfaces every HTTP/2-capable component across your services — nginx, Envoy, gRPC, Netty, and language-runtime stacks alike — so you get one accurate view of exposure instead of chasing it component by component. Our reachability analysis then tells you which of those vulnerable HTTP/2 code paths are actually load-bearing in your production request flow, separating internet-facing ingress that needs emergency patching from internal, low-exposure services that can follow normal cycles. Griffin AI correlates that exposure with KEV and EPSS signal to prioritize Rapid Reset-class findings above routine CVEs automatically, and where a fix is available, Safeguard can open an auto-fix PR that bumps the affected dependency to its patched version and routes it straight to your team for review — cutting the time between disclosure and a merged fix from weeks to hours.