October 11, 20230 mins read
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.
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
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
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
Alternatively, if they have mitigated the risk in other ways, they can change the severity to Low to accurately reflect in their reports.
Re-test after adding custom severity policies
After adding a custom severity policy, projects must be retested for the changed severities to repopulate.
Next steps in responding to the HTTP/2 vulnerabilities
Apply configuration changes and mitigations through infrastructure providers and CDNs to reduce the exposure to this novel DDoS technique.
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.
When available, apply fixes by updating impacted libraries to fix versions, and build new container images with fixed base images.
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.