What HTTP/2 Rapid Reset does
Disclosed in October 2023 as CVE-2023-44487, HTTP/2 Rapid Reset opens a stream and immediately sends RST_STREAM to cancel it, then repeats — endlessly. Each request is cheap for the client but still costs the server the work of setting up and tearing down a stream, and because the streams are cancelled they sidestep the connection's concurrency limit. It drove some of the largest floods ever recorded.
How ddos-sim.com simulates it safely
ddos-sim.com speaks genuine HTTP/2 to a single verified domain pinned to a public address, opening and resetting streams within the rate and concurrency limits for that domain. It reproduces the request-accounting pressure of the real technique so you can verify your patch level and tuning — no spoofing, one verified target.
Every run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.
What the test exercises
- Whether your HTTP/2 stack is patched for CVE-2023-44487
- Per-connection stream accounting and reset handling
- Proxy, load-balancer, and origin behavior under rapid stream churn
- Mitigations such as capping resets per connection
- CPU and memory cost of stream setup/teardown
When to run an HTTP/2 rapid reset test
Run an HTTP/2 rapid reset test when you need to confirm your servers are patched and configured against CVE-2023-44487.
- You run HTTP/2 origins or proxies and want evidence the rapid-reset mitigation (stream limits, per-connection caps) is active.
- You've patched for CVE-2023-44487 and want to verify the fix under real stream open-and-cancel churn.
- A CDN or load balancer speaks HTTP/2 to clients and you need to confirm it, not the origin, absorbs the pattern.
How to run a http/2 rapid reset test
- Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
- Add the
http2_rapid_resetcommand to a timeline in the portal and set the target path or port, rate, and duration. - Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
- Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
- Read the results. Review the recorded latency, status codes, and worker timeline to find where your service starts to bend.
Reading the results
Resilient: Per-connection stream limits cap the churn, CPU stays bounded, and the server keeps serving other streams and connections normally.
Under strain: CPU climbs sharply with request rate, the server falls behind, or throughput collapses — a sign the rapid-reset mitigation isn't engaging.
Availability & limits
HTTP/2 Rapid Reset is priced per engagement — request a quote. Verify your domain before it runs.
Frequently asked questions
What is CVE-2023-44487?
It is the HTTP/2 Rapid Reset vulnerability disclosed in October 2023, in which rapidly opening and cancelling HTTP/2 streams lets an attacker generate huge request volume that bypasses the usual concurrency limit. This test reproduces that pattern against your own server.
How do I know if I am protected?
A patched, well-tuned HTTP/2 stack caps or penalizes excessive stream resets per connection. Running the test against your verified domain shows whether request accounting and mitigations hold up under rapid reset churn.
Rehearse the http/2 rapid reset against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.
Build a test plan