Find and fix HTTP/2 rapid reset zero-day vulnerability CVE-2023-44487

Researchers and vendors have conducted an investigation into volumetric DDoS attacks in the wild between August – October 2023 that has resulted in the discovery of a novel “rapid reset” technique that leverages stream multiplexing, a feature of the widely-adopted HTTP/2 protocol.

Disclosed today, the HTTP/2 rapid reset vulnerability is being tracked as CVE-2023-44487 and has been designated a High severity vulnerability with a CVSS score of 7.5 (out of 10).

The vulnerability is believed to impact every web server implementing HTTP/2 and carries the potential for extremely large volumetric DDoS attacks if exploited. If you are impacted by this CVE in an application or operating system package AND that package is present in an application deployed with internet access, please consider:

• Checking with your infrastructure and/or CDN provider (e.g. Cloudflare, Google Cloud, AWS, Akamai) to ensure you're mitigated from this vulnerability.

• Upgrading the package if a remediation is available. For some packages, remediated versions have already been published.

Snyk is not impacted by this vulnerability

All externally accessible Snyk services are protected, being hosted either behind Akamai or cloud load balancers which have previously been mitigated.

Mitigation via infrastructure provider

It is first recommended that organizations apply configuration changes and mitigations through infrastructure providers and CDNs where necessary to reduce the exposure to this novel DDoS technique. 

• Cloudflare: HTTP/2 Rapid Reset: deconstructing the record-breaking attack

• Google: How it works: The novel HTTP/2 ‘Rapid Reset’ DDoS attack

• AWS: CVE-2023-44487 - HTTP/2 Rapid Reset Attack

• NGINX: HTTP/2 Rapid Reset Attack Impacting NGINX Products

• Azure: Microsoft Response to Distributed Denial of Service (DDoS) Attacks against HTTP/2

Though exposure from this vulnerability can be successfully mitigated via infrastructure providers or cloud load balancers, it is important not to stop there and to take remediation steps at the source by upgrading all packages that may be impacted by this CVE.

Upgrading packages to remediated versions

Next, organizations should check if any of their container images or open source ecosystems are impacted and apply updates if available. You can find all the advisories for this specific CVE in the Snyk Vulnerability Database by selecting your package manager(s) or container distro(s).

Detecting the HTTP/2 vulnerabilities with Snyk

To see if your projects or applications are affected, you can filter by "CVE-2023-44487" in the Issue Detail report to find the projects that contain a package with the vulnerability.

Testing your projects using the Snyk CLI

There are various ways to detect and remediate the HTTP/2 vulnerability — for free — using Snyk. Using the Snyk CLI, you can test your projects locally.

Testing projects that use package managers

For applications, run snyk test from the Snyk CLI to compare dependencies in your repository to detect individual packages and their vulnerabilities. You can use the Snyk CLI to test all projects using snyk test --all-projects and you can specify the package manager via the --package-manager= flag with an option to specify a non-standard requirements file via the --file= flag.

Currently, supported arguments for the --package-manager= flag include cocoapods, composer, golangdep, maven, npm, pip, and more (refer to the CLI for more options).

Testing with the CLI for C++ projects

For applications, run snyk test --unmanaged from the Snyk CLI to compare unmanaged dependencies in your repository to detect individual packages and their vulnerabilities.

Testing with the CLI for container images

For containers, run snyk container test to detect operating system packages that depend on vulnerable versions of HTTP/2. For best results, include both the image name and the path to the Dockerfile that created the image, for example:

snyk container test debian:10 --file=Dockerfile

Testing your projects using an Git/SCM integration

Importing your project into Snyk using our supported SCM integrations (GitHub, Bitbucket, GitLab, Azure Repos) will automatically trigger a test, which will enable you to use the Snyk UI to identify, prioritize, and fix the http/2 vulnerabilities in your projects when a fix is available. 

Fixing the HTTP/2 vulnerabilities

Once you've identified vulnerable packages and containers in your environment, you can remediate with Snyk. The methods are similar, but you've got a couple of options.

For open source components

• Automatic fix: Connect Snyk to your Git repositories so it can raise pull requests to update your dependency graph where possible, then rebuild your application.

• Manual fix (option 1): If you have a direct dependency on a component that is impacted by the HTTP/2 vuln, you can upgrade your dependency file to specify the corresponding fix version, then rebuild your application.

• Manual fix (option 2): If your application uses a component impacted by the HTTP/2 vuln as an indirect or transitive dependency, identify a version of your direct dependency that pulls in an updated version of the impacted dependency, then rebuild your application. Alternatively, if overrides are supported by your package manager, you could treat the dependency as direct and include a fixed version in your requirements file.

For container images

• Automatic fix: Connect Snyk to your Git repositories so it can raise pull requests to update your Dockerfile base image where possible. Preview if the suggested base image upgrade still carries the vulnerability by using https://snyk.io/test/docker/<image_name> , then rebuild your container once you have identified an acceptable upgrade path.

• Manual fix: If your image includes a vulnerable version of the vulnerable packages and a base image upgrade is not available or desired, you can upgrade it yourself using the remediation advice from Snyk Container. 

If a fix is not yet available

If the option to upgrade a specific package or container is unavailable, this particular vulnerability can be mitigated prior to the call path, as described above. For instance, if a certain service is affected by this vulnerability and is exposed to the internet via a cloud load balancer, it will not be impacted because all major cloud providers have already mitigated this risk at their level.

How to reprioritize this vulnerability using custom policies?

If you'd like to increase the priority of the HTTP/2 vuln to increase visibility you can leverage Snyk’s custom policies. These can be used to reprioritize these vulnerabilities. The CVE has been assigned a value of High currently, however, if customers want to change that priority, they can create a policy that impacts CVE-2023-44487 to change the severity to Critical.

Alternatively, if they have mitigated the risk in other ways, they can change the severity to Low to accurately reflect in their reports. 

Next steps in responding to the HTTP/2 vulnerabilities

1. Apply configuration changes and mitigations through infrastructure providers and CDNs to reduce the exposure to this novel DDoS technique. 

2. Test your projects with Snyk using the methods outlined in this article. To get started, sign up for a free Snyk account, then import and scan all potentially impacted projects using the import wizard.

3. When available, apply fixes by updating impacted libraries to fix versions, and build new container images with fixed base images.

4. Continue to monitor this situation as it unfolds, ensure you’re following us on Twitter/X (@snyksec), and check back on the Snyk Blog for any developments as they occur. Snyk’s security teams will update our resources regularly with the latest updates.