CVE-2023-44487: HTTP/2 rapid reset can cause excessive work in net/http
Summary
CVE-2023-39325: HTTP/2 rapid reset can cause excessive work in net/http. Affects stdlib across 2 version ranges.
< 1.20.10
>= 1.21.0-0, < 1.21.3
Fixed in 1.20.10 or 1.21.3, depending on the release line you run. How to fix ↓
Also tracked for
- golang · Bitnami
- golang-1.15 · Debian:11
- golang.org/x/net · Go
The same CVE-2023-39325 is tracked separately for each ecosystem and vendor. Its fix information is the same; the package and affected versions differ.
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
The stdlib package in Go provides a set of standard libraries for the Go programming language. The net/http package in the stdlib is used for building HTTP servers and clients. It includes functions like ListenAndServe, Serve, and Server.Serve, which handle HTTP requests and responses. The golang.org/x/net package is an extension to the stdlib package and provides additional networking capabilities. The http2 subpackage in golang.org/x/net implements the HTTP/2 protocol.
The vulnerability identified as CVE-2023-44487 affects the net/http and golang.org/x/net/http2 packages in Go. It allows a malicious HTTP/2 client to create and reset requests rapidly, leading to excessive resource consumption on the server. This can result in a denial-of-service (DoS) attack, where the server becomes overwhelmed and unable to handle legitimate requests.
Vulnerability Detail
The vulnerability arises due to the behavior of the HTTP/2 protocol in the net/http and golang.org/x/net/http2 packages. When a malicious client sends a large number of requests and immediately resets them, it can cause the server to consume excessive resources. The server allows a maximum number of concurrent streams (requests) defined by the http2.Server.MaxConcurrentStreams setting. By resetting an in-progress request, the attacker can create a new request while the previous one is still executing.
To mitigate this issue, the HTTP/2 servers now limit the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when the limit is reached will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. The default stream concurrency limit is 250 streams per HTTP/2 connection, but it can be adjusted using the golang.org/x/net/http2 package's Server.MaxConcurrentStreams setting.
How To Fix
Latest published version: go1.25.5 as of 22 Oct 2026
go get stdlib@vgo1.25.5Upgrading to it may include breaking changes; the versions below are the minimum fixed release for this vulnerability.
If you can't move to the latest
The minimum fixed version depends on the release line you run.
-
< 1.20.101.20.10go get stdlib@v1.20.10 -
>= 1.21.0-0, < 1.21.31.21.3go get stdlib@v1.21.3
Tip — Not sure which release line you're on? Vulert can find the fix for the version you are using. Scan free →
Workaround
There is no specific workaround mentioned for this vulnerability. However, as a general best practice, it is recommended to implement rate limiting or request throttling mechanisms in the server application to mitigate the impact of DoS attacks. These mechanisms can help limit the number of requests processed per client or per time interval, preventing excessive resource consumption.
Conclusion
The vulnerability CVE-2023-44487 in the net/http and golang.org/x/net/http2 packages allows a malicious HTTP/2 client to consume excessive server resources, leading to a denial-of-service (DoS) condition. To fix this vulnerability, developers should update to the fixed versions of the affected packages. Implementing rate limiting or request throttling mechanisms in the server application can also help mitigate the impact of DoS attacks. For further support on vulnerability remediation, contact DevNack.com.
See every vulnerability recorded for stdlib →
FAQ
The vulnerability allows a malicious HTTP/2 client to consume excessive server resources by rapidly creating and resetting requests. This can lead to a denial-of-service (DoS) condition, where the server becomes overwhelmed and unable to handle legitimate requests.
You can use the Vulert Playground at Vulert Scanner to check if your application is affected by this vulnerability. The playground allows you to analyze your application's dependencies using the Gopkg.lock file without requiring any code or installation. It provides real-time monitoring and alerts for open-source vulnerabilities in software.
The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This means that a single client can have up to 250 concurrent requests to the server. This limit can be adjusted using the golang.org/x/net/http2 package's Server.MaxConcurrentStreams setting.
While there is no specific workaround mentioned for this vulnerability, implementing rate limiting or request throttling mechanisms in the server application can help mitigate the impact of DoS attacks. These mechanisms can limit the number of requests processed per client or per time interval, preventing excessive resource consumption.
To update the affected packages, developers should use a package manager or dependency management tool. For projects using Go modules, the go.mod file can be updated with the required versions of the packages. Running 'go get -u' or 'go mod tidy' will fetch the updated versions. Manual installation can also be performed by downloading the source code and building it using the Go compiler.
References
Related vulnerabilities
Recent vulnerabilities recorded for stdlib.
