Nginx and CVE-2023-44487: How to Fix HTTP/2 Rapid Reset

Nginx CVE-2023-44487, known as the HTTP/2 Rapid Reset attack, is a denial-of-service flaw in the HTTP/2 protocol itself, and nginx already resists it when run with default settings; the fix is to keep or restore those defaults, apply the current patched build, and add rate limits so a client cannot exhaust server resources. It is not an nginx-specific code bug the way a buffer overflow would be. It is a weakness in how HTTP/2 allows a client to open and immediately cancel streams, which nginx handles well unless you have widened its concurrency limits.

CVE-2023-44487 was disclosed on October 10, 2023, alongside the largest DDoS attacks recorded at the time, and CISA issued an alert the same day. Because it targets the protocol, essentially every HTTP/2 server was in scope, including nginx, though the impact varied a lot with configuration.

How the Rapid Reset attack works

HTTP/2 multiplexes many streams over one TCP connection and lets a client cancel a stream at any time by sending an RST_STREAM frame. Rapid Reset abuses that: the attacker opens a stream, sends a request, and immediately resets it, over and over, thousands of times per connection. The server does the work of setting up and tearing down each request while the reset means it never has to complete the response. The result is resource starvation, and it scales devastatingly across a botnet.

The clever part from the attacker's side is that canceled streams historically did not count against the concurrent-stream limit, so a single connection could churn through an enormous number of requests without ever hitting the cap that was supposed to protect the server.

Where nginx stands

Per F5's guidance for its NGINX products, nginx effectively prevents Rapid Reset using its default keepalive behavior. The default keepalive_requests limit (1000) and http2_max_concurrent_streams (128) mean a connection that churns through streams gets closed and reset before it can do meaningful damage. The exposure appears when an operator has raised keepalive_requests far above the default in pursuit of performance, which removes the natural brake.

So for most nginx deployments the honest answer is that you are largely protected out of the box. The CVE-2023-44487 fix for nginx is less about an emergency patch and more about confirming your configuration has not defeated the built-in protection, then updating to a current release.

The configuration fix

Confirm these directives are at safe values. If you never changed them, you are already there:

http {
    # Close and reset a connection after this many requests
    keepalive_requests 1000;

    server {
        listen 443 ssl;
        http2 on;

        # Cap concurrent HTTP/2 streams per connection
        http2_max_concurrent_streams 128;

        # Limit connections and request rate per client
        limit_conn_zone $binary_remote_addr zone=perip:10m;
        limit_req_zone  $binary_remote_addr zone=reqs:10m rate=20r/s;

        location / {
            limit_conn perip 20;
            limit_req  zone=reqs burst=40 nodelay;
        }
    }
}

The limit_conn and limit_req directives are the durable defenses. They cap how many connections and requests a single client IP can drive, which blunts Rapid Reset regardless of stream-cancellation tricks. Set them to values that fit your legitimate traffic; the numbers above are illustrative starting points, not universal recommendations.

If you cannot patch immediately and are under active attack, disabling HTTP/2 on the affected server block (removing http2 on;) drops you back to HTTP/1.1, which is not vulnerable to this specific attack. That is a blunt fallback with a performance cost, not a permanent fix.

Patching

Beyond configuration, update to a current nginx build. Around this disclosure, nginx published updated open-source releases in the 1.25.x line, and F5 shipped patched NGINX Plus packages (the R29 and R30 patch releases). NGINX open-source users should rebuild from the latest codebase; NGINX Plus customers should move to the latest packages. Verify the exact fixed version for your distribution against your OS vendor's advisory or the official nginx changelog before you rely on it, since packaged versions differ from the upstream release. Note that a closely related nginx-side issue, CVE-2023-39325, was addressed in the same window, so vendor advisories often reference both together.

Finding exposure across your fleet

The hard part at scale is not fixing one server; it is knowing which of your hundreds of services still run a vulnerable HTTP/2 stack, including nginx sitting inside container images you did not build directly. A base image can carry an old nginx that your application inherited silently. Scanning your container images and SBOMs for the affected nginx versions surfaces those. An SCA tool such as Safeguard can flag a vulnerable nginx pulled in transitively through a base image, which is exactly the kind of exposure a config review of your own nginx.conf would miss.

To close out CVE-2023-44487 across a real environment:

• Confirm keepalive_requests and http2_max_concurrent_streams are at or near defaults on every nginx instance.
• Add limit_conn and limit_req as a standing defense.
• Patch to a current nginx release and verify the version against your vendor's advisory.
• Scan container images and SBOMs to find nginx versions you inherited rather than installed.

FAQ

Is nginx vulnerable to CVE-2023-44487?

Nginx is affected by the protocol-level attack like all HTTP/2 servers, but it resists Rapid Reset with default settings thanks to its keepalive and concurrent-stream limits. The risk rises mainly when those limits have been raised well above defaults.

What is the fastest CVE-2023-44487 fix for nginx?

Confirm keepalive_requests and http2_max_concurrent_streams are near their defaults, add limit_conn and limit_req rate limits, and update to a current nginx build. If under active attack and unable to patch, temporarily disabling HTTP/2 removes exposure to this specific attack.

When was CVE-2023-44487 disclosed?

October 10, 2023. CISA published an alert the same day, and it coincided with record-setting DDoS attacks that exploited the HTTP/2 Rapid Reset technique in the wild.

How do I find vulnerable nginx versions I did not install directly?

Scan your container images and SBOMs. Base images frequently bundle an nginx your application inherits, and a dependency or image scan surfaces those versions that a review of your own configuration files would never reveal.