CVE-2023-44487

What it actually does

This vulnerability, known as 'HTTP/2 Rapid Reset', resides in the HTTP/2 protocol itself. An attacker can abuse the stream cancellation feature by sending a HEADERS frame to open a stream and then immediately sending an RST_STREAM frame to cancel it. By repeating this process at a high rate within a single HTTP/2 connection, an attacker forces the server to continuously allocate and deallocate resources for each stream. This rapid churn exhausts server CPU and memory, leading to a denial of service (DoS) where the server becomes unresponsive to legitimate traffic.

Why it matters to the business

Exploitation of this vulnerability leads to a denial of service, causing critical websites, APIs, and online applications to become unavailable. This results in direct business consequences such as lost revenue, operational disruption, customer dissatisfaction, and reputational damage. Given that this vulnerability is actively exploited in the wild and is listed on the CISA KEV catalog, any public-facing service using HTTP/2 is at a high and immediate risk of being targeted, making prompt mitigation essential.

How an attack unfolds

An unauthenticated, remote attacker first identifies a target server that supports the HTTP/2 protocol. The attacker then establishes a standard HTTP/2 connection. Within this single connection, they send a large number of HEADERS frames, each initiating a new request stream. Immediately after sending each HEADERS frame, the attacker sends a corresponding RST_STREAM frame to cancel that same stream. This 'rapid reset' technique bypasses typical limits on the number of concurrent active streams, as the streams are never fully processed. The server is forced into a high-frequency loop of setting up and tearing down streams, which consumes excessive CPU resources and ultimately leads to resource exhaustion, rendering the service unavailable to legitimate users.

How to fix it

The primary remediation is to apply security patches provided by your software vendors. This includes web servers (e.g., Apache, Nginx), load balancers, reverse proxies, and Content Delivery Networks (CDNs). For applications using the nghttp2 library directly, update to a version incorporating the fix from commit 6f41cc72718a1c0fca39e83d9537c1a91efa6d18. If patching is not immediately feasible, consider implementing rate limits on new streams per connection or connections per IP address at the network edge. As a last resort, you can temporarily disable HTTP/2 support on your servers, but be aware of potential performance degradation.

How to confirm the fix worked

To validate the fix, first confirm that all relevant web servers, proxies, and libraries have been upgraded to the patched versions recommended by their respective vendors. Review server configurations to ensure any vendor-recommended mitigation settings, such as new rate-limiting parameters for HTTP/2 streams, are correctly implemented. Monitor server performance metrics like CPU utilization and memory usage; after patching, the server should remain stable during normal traffic loads. For a more active test, use a security testing tool in a pre-production environment to simulate a high rate of HTTP/2 stream resets and verify that the patched server handles the traffic without significant performance degradation or crashing.

Typical attack path

1. The attacker identifies a public-facing web server, load balancer, or API gateway that supports HTTP/2.
2. The attacker establishes a single TCP connection and completes the HTTP/2 protocol handshake.
3. Within the connection, the attacker sends a high volume of HEADERS frames to open numerous streams in quick succession.
4. Immediately after each HEADERS frame, the attacker sends an RST_STREAM frame to cancel the corresponding stream.
5. The server's CPU and memory are consumed by the rapid creation and cancellation of streams.
6. The server becomes overloaded and unresponsive, resulting in a denial of service for legitimate users.

How to detect it

To detect exploitation, monitor web server, load balancer, and CDN logs for an anomalously high rate of HTTP/2 streams being created and immediately closed from a single source IP address. In network traffic captures, the attack pattern appears as a high volume of HTTP/2 RST_STREAM frames. A key indicator is a sudden and sustained spike in CPU utilization on web servers that is not accompanied by a corresponding increase in legitimate user traffic or data throughput. Security information and event management (SIEM) systems can be configured to alert when the rate of stream resets from a single client exceeds a predefined threshold.

What your security team should do

• Immediately apply vendor-supplied security patches to all internet-facing systems that use HTTP/2, as this vulnerability is under active, widespread exploitation.
• Prioritize patching for critical revenue-generating applications and public-facing APIs.
• If patching is delayed, engage your WAF or DDoS mitigation provider to deploy specific rules to detect and block the HTTP/2 Rapid Reset attack pattern.
• Configure monitoring and alerting for sudden, sustained spikes in CPU utilization on web front-ends that are not correlated with a legitimate traffic increase.