Detect & Mitigate HTTP/2: Rapid Reset Vulnerabilities, Adoption, impact mitigations for CVE-2023-44487

HTTP/2, Rapid Reset, Explaination, vulenrability, DDoS attacks, zero day, CVE-2023-44487


HTTP/2, Rapid Reset, Explaination, vulenrability, DDoS attacks, zero day, CVE-2023-44487

In what could be the biggest DDoS ever registered and in a month already full of advisories like LIBCURL Vulnerability HTTP/2 has been affected by a vulnerability CVE-2023-44487 aka Rapid Reset that could impact basically every web server and has been exploited in the wild. This blog aims to shed light on various aspects of HTTP/2, answering key questions that many have about this web protocol’s vulnerabilities and mitigations. The attackers leveraged this vulnerability to deploy a massive DDoS attack: Amazon mitigated attacks at a rate of 155 million requests per second, Cloudflare at 201 million rps, and Google endured a record-breaking 398 million rps. This vulnerability was under active attack in August.

What is HTTP/2?

HTTP/2 is the second major version of the HTTP network protocol, used by the World Wide Web. It brings key improvements over HTTP 1.1, such as smaller header sizes and multiplexing—the ability to send multiple requests for data in parallel over a single TCP connection. Unlike HTTP 1.1, which is text-based, HTTP/2 is binary-based, making it more compact and more efficient in terms of parsing.

HTTP/2, Rapid Reset, Explaination, vulenrability, DDoS attacks, zero day,

for each element of that page (CSS, images etc) HTTP 2 is a binary protocol that utilises multiplexing, which allows multiple requests and responses to be sent simultaneously over a single connection

HTTP/2, Rapid Reset, Explaination, vulenrability, DDoS attacks, zero day,

Daniel Cuthbert has done a fantastic analysis on HTTP 1 vs 2 and Rapid Reset vulnerability

Is HTTP/2 Vulnerable?

The short answer is yes. Like any technology, HTTP/2 is not immune to vulnerabilities. A notable example is CVE-2023-44487, a bug that exploits the HTTP/2 protocol’s feature called “streams.” Streams are multiplexed requests and responses with unique identifiers. The vulnerability lies in the RST_STREAM frame, which allows for immediate termination of a stream. Malicious actors have found ways to abuse this feature for DDoS attacks, making it a significant security concern.

Vendor Advisories and Statements for CVE-2023-44487 Rapid Reset

Several vendors have issued advisories and fixes for this vulnerability:

  • Apache Tomcat: Fixed in 8.5.94
  • AWS: No statement as of yet
  • F5: No statement as of yet
  • Microsoft IIS: No statement as of yet
  • Microsoft MsQuic: Fixed in 2.2.3
  • Nginx: Full details in their blog
  • nghttp2 library: Fixed in 1.57.0

CISA Advisory CVE-2023-44487 Rapid Reset

The Cybersecurity and Infrastructure Security Agency (CISA) has also advised on this vulnerability. For more details, you can refer to CISA’s advisory on CVE-2023-44487.

Why is HTTP/2 Not Widely Used?

Despite its advantages, HTTP/2 has not seen universal adoption. Several factors contribute to this:

  1. Compatibility Issues: Older systems and browsers may not support HTTP/2, making it less appealing for websites that cater to a broad audience.
  2. Lack of Awareness: Many website owners are not fully aware of the benefits that HTTP/2 can bring, leading to slower adoption rates.
  3. Server Updates: Transitioning to HTTP/2 often requires updates to web servers, which some organizations may find cumbersome or risky.

How to Change from HTTP 1.1 to HTTP 2?

Transitioning from HTTP 1.1 to HTTP/2 is generally straightforward but requires careful planning:

  1. Server Software: Ensure your web server software supports HTTP/2. Popular web servers like Apache and Nginx have HTTP/2 support.
  2. SSL/TLS: HTTP/2 requires SSL/TLS for secure connections, so make sure you have an SSL certificate installed.
  3. Configuration: Update your web server’s configuration files to enable HTTP/2.
  4. Testing: Before fully transitioning, test the HTTP/2 settings on a staging server to identify any issues.
  5. Monitoring: After the transition, monitor performance and error logs to ensure everything is running smoothly.

Is HTTP 1.1 Still Being Used?

Yes, HTTP 1.1 is far from obsolete. Many older systems and websites still use HTTP 1.1 due to compatibility reasons, lack of resources, or simply because they don’t require the performance improvements that HTTP/2 offers.

The Scale of the Attack: A New Benchmark in Cyber Threats

On August 25, 2023, the cybersecurity community was put on high alert. Automated DDoS systems began detecting and mitigating unusually large HTTP attacks against numerous targets. While DDoS attacks are not new, the scale of this particular attack was unprecedented. The attack eventually peaked at an astonishing 201 million requests per second, nearly tripling the size of the previous largest attack on record.

The Botnet Factor

What makes this attack even more alarming is the relatively small size of the botnet used to execute it. The attacker generated this massive attack using a botnet of just 20,000 machines. To put this in perspective, botnets today consist of hundreds of thousands or even millions of machines.

The Potential for Widespread Impact

The implications are staggering because the entire web typically sees only between 1–3 billion requests per second. Using this method, it’s conceivable that an attacker could focus an entire web’s worth of requests on a small number of targets, effectively crippling them. This raises serious questions about the preparedness of current cybersecurity measures to handle attacks of this scale.

Mitigation Strategies for CVE-2023-44487 Rapid Reset

One way to mitigate the vulnerabilities in HTTP/2 is to disable it on your web server. Microsoft provides a guide on how to do this using the Registry Editor. However, it’s crucial to exercise caution when using the Registry Editor, as incorrect usage can lead to severe system issues.

Here’s a step-by-step guide based on Microsoft’s recommendations:

  1. Open Registry Editor: Click Start, click Run, type Regedit in the Open box, and click OK.
  2. Locate Subkey: Navigate to HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters.
  3. Edit DWORD Values: Set DWORD type values EnableHttp2TIs and EnableHttp2Cleartext to 0 to disable HTTP/2 or 1 to enable it.
  4. Restart: Exit the Registry Editor and restart your computer.

For more details, you can refer to Microsoft’s update guide on CVE-2023-44487.

Disabling HTTP/2 in NGINX is not necessary. Simply ensure you have configured:

Testing and Scanning Tools for CVE-2023-44487

For those interested in testing their web servers for HTTP/2 support or vulnerability to CVE-2023-44487, you can use this HTTP/2 scanner Python script. Credit to Daniel Cuthbert

Alternatively, you can use this Python script, please use at your own risk, and review the code before running it

How Phoenix Security Can Help Identify HTTP/2 Vulnerability CVE-2023-44487 in Your Products

HTTP/2, Explaination, vulenrability, DDoS attacks, zero day, CVE-2023-44487 , phoenix security

Phoenix Security serves as a beacon for security professionals aiming to pinpoint the vulnerabilities at scale, while CVE-2023-44487 is fairly new you should be able to identify the vulnerabilities in the vulnerability screen and asset screen vulnerability within their systems.

HTTP/2, Explaination, vulenrability, DDoS attacks, zero day, CVE-2023-44487 , phoenix security

You can also scan with the above scripts and import the results into phoenix to have an asset inventory

Previous Issues of Vulnerability Weekly




Francesco is an internationally renowned public speaker, with multiple interviews in high-profile publications (eg. Forbes), and an author of numerous books and articles, who utilises his platform to evangelize the importance of Cloud security and cutting-edge technologies on a global scale.

Discuss this blog with our community on Slack

Join our AppSec Phoenix community on Slack to discuss this blog and other news with our professional security team

From our Blog

IronWorm is a Rust-built npm supply chain worm that distributed a 976 KB eBPF rootkit and Tor C2 across 37 packages from a single compromised account, with no CVE assigned. It uses npm’s own Trusted Publishing OIDC flow to mint publish credentials from CI runners and self-replicate. CVE-based scanners had zero detection surface at the point of compromise.
Daniel Reeves
On June 1, 2026, 32 packages in the @redhat-cloud-services npm scope — totalling 116,991 weekly downloads — were backdoored by Miasma, a new Shai-Hulud variant that steals credentials across AWS, GCP, Azure, and Kubernetes through a preinstall hook. No CVE exists. Every malicious version passed npm Trusted Publishing validation using legitimate OIDC-issued tokens, leaving CVE-dependent scanners with zero detection surface during the active exposure window.
Francesco Cipollone
AI now generates working exploits in 10–15 minutes. Verizon’s DBIR confirms software vulnerabilities have overtaken stolen credentials as the top breach entry point. The NCSC and Bank of England have formally demanded automated, at-scale remediation. This analysis breaks down why traditional vulnerability management is broken, what the 2026 supply-chain attack catalogue tells us, and how to close the tap and burn down the backlog before the patch wave hits.
Marcus Webb
TrapDoor is an active supply chain campaign hitting npm, PyPI, and Crates.io simultaneously — 34 malicious packages, 384 artifact versions, confirmed since May 19, 2026. The campaign steals SSH keys, AWS credentials, GitHub tokens, and crypto wallet keystores, while silently poisoning AI coding assistants through hidden zero-width Unicode injected into .cursorrules and CLAUDE.md files. Zero CVEs assigned. Standard scanners return zero findings.
Sarah Mitchell
An attacker with push access to the Laravel-Lang GitHub organization force-rewrote 700+ git tags across 4 Composer packages on May 22, 2026, injecting an RCE backdoor that fires on every PHP application boot. No CVE was assigned — version pinning offered zero protection. The attack stole CI/CD, cloud, and Kubernetes credentials in 3.16 seconds flat.
Francesco Cipollone
MEGALODON_CI is an active zero-CVE campaign poisoning GitHub Actions workflow files across 3,500+ confirmed public repositories. Automated commits inject a base64-encoded credential harvester that exfiltrates AWS, GCP, and Azure secrets, OIDC tokens, SSH keys, and package registry credentials in a single runner execution. No CVE exists — every traditional scanner is blind to it.
Sarah Mitchell
Contents
Derek

Derek Fisher

Head of product security at a global fintech

Derek Fisher – Head of product security at a global fintech. Speaker, instructor, and author in application security.

Derek is an award winning author of a children’s book series in cybersecurity as well as the author of “The Application Security Handbook.” He is a university instructor at Temple University where he teaches software development security to undergraduate and graduate students. He is a speaker on topics in the cybersecurity space and has led teams, large and small, at organizations in the healthcare and financial industries. He has built and matured information security teams as well as implemented organizational information security strategies to reduce the organizations risk.

Derek got his start in the hardware engineering space where he learned about designing circuits and building assemblies for commercial and military applications. He later pursued a computer science degree in order to advance a career in software development. This is where Derek was introduced to cybersecurity and soon caught the bug. He found a mentor to help him grow in cybersecurity and then pursued a graduate degree in the subject.

Since then Derek has worked in the product security space as an architect and leader. He has led teams to deliver more secure software in organizations from multiple industries. His focus has been to raise the security awareness of the engineering organization while maintaining a practice of secure code development, delivery, and operations.

In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

Jeevan Singh

Jeevan Singh

Founder of Manicode Security

Jeevan Singh is the Director of Security Engineering at Rippling, with a background spanning various Engineering and Security leadership roles over the course of his career. He’s dedicated to the integration of security practices into software development, working to create a security-aware culture within organizations and imparting security best practices to the team.
In his role, Jeevan handles a range of tasks, from architecting security solutions to collaborating with Engineering Leadership to address security vulnerabilities at scale and embed security into the fabric of the organization.

James

James Berthoty

Founder of Latio Tech

James Berthoty has over ten years of experience across product and security domains. He founded Latio Tech to help companies find the right security tools for their needs without vendor bias.

christophe

Christophe Parisel

Senior Cloud Security Architect

Senior Cloud Security Architect

Chris

Chris Romeo

Co-Founder
Security Journey

Chris Romeo is a leading voice and thinker in application security, threat modeling, and security champions and the CEO of Devici and General Partner at Kerr Ventures. Chris hosts the award-winning “Application Security Podcast,” “The Security Table,” and “The Threat Modeling Podcast” and is a highly rated industry speaker and trainer, featured at the RSA Conference, the AppSec Village @ DefCon, OWASP Global AppSec, ISC2 Security Congress, InfoSec World and All Day DevOps. Chris founded Security Journey, a security education company, leading to an exit in 2022. Chris was the Chief Security Advocate at Cisco, spreading security knowledge through education and champion programs. Chris has twenty-six years of security experience, holding positions across the gamut, including application security, security engineering, incident response, and various Executive roles. Chris holds the CISSP and CSSLP certifications.

jim

Jim Manico

Founder of Manicode Security

Jim Manico is the founder of Manicode Security, where he trains software developers on secure coding and security engineering. Jim is also the founder of Brakeman Security, Inc. and an investor/advisor for Signal Sciences. He is the author of Iron-Clad Java: Building Secure Web Applications (McGraw-Hill), a frequent speaker on secure software practices, and a member of the JavaOne Rockstar speaker community. Jim is also a volunteer for and former board member of the OWASP foundation.

Join our Mailing list!

Get all the latest news, exclusive deals, and feature updates.

The IKIGAI concept
Protected By
Shield Security PRO