CVE-2023-39325 in Google
Summary
by MITRE • 10/25/2023
A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/27/2025
This vulnerability represents a sophisticated resource exhaustion attack targeting HTTP/2 servers through manipulated concurrent stream handling. The flaw allows malicious clients to exploit the protocol's reset mechanism to bypass normal concurrency limits, creating a persistent resource consumption scenario that can lead to server degradation or complete service unavailability. The vulnerability specifically targets the Go programming language's HTTP/2 implementation where the server's handling of concurrent streams does not properly account for the reset behavior that enables attackers to maintain more active processing goroutines than intended.
The technical implementation of this vulnerability relies on the HTTP/2 protocol's stream management where clients can reset in-flight requests to immediately free up connection resources while maintaining their ability to create new requests. This behavior creates a race condition within the server's goroutine management system where the number of executing handler goroutines can exceed the configured MaxConcurrentStreams limit. The attack exploits the fact that while the total number of requests is bounded, the reset mechanism allows attackers to effectively create new requests without waiting for the completion of previous ones, leading to a situation where the server's handler goroutine pool becomes saturated with concurrent processing tasks.
The operational impact of this vulnerability extends beyond simple resource exhaustion to potentially compromise the entire server infrastructure. When attackers successfully exploit this flaw, they can cause the server to allocate excessive memory and CPU resources to handle concurrent goroutines, leading to denial of service conditions that affect legitimate users. The vulnerability affects systems using Go's standard library HTTP/2 server implementation and the golang.org/x/net/http2 package, making it particularly concerning for web applications, API gateways, and microservices that rely on HTTP/2 for performance and efficiency. The default concurrency limit of 250 streams per connection provides a baseline protection, but the reset mechanism allows attackers to effectively bypass this limit and maintain higher concurrent processing levels.
The mitigation strategy implemented in the patched versions addresses the core issue by enforcing stricter bounds on executing handler goroutines, ensuring that the number of simultaneously running handlers cannot exceed the configured MaxConcurrentStreams value. This fix introduces queuing mechanisms for new requests when the concurrency limit is reached, preventing the accumulation of excessive goroutines while maintaining server stability. The solution also includes connection termination when request queues grow too large, providing additional protection against resource exhaustion. Security practitioners should update their Go applications to versions containing this fix and consider adjusting the MaxConcurrentStreams parameter based on their server capacity and expected load patterns. The fix aligns with security best practices for protocol implementation and resource management, addressing the CWE-400 vulnerability category related to resource exhaustion and the ATT&CK technique T1499.004 for resource exhaustion attacks targeting network services. Organizations should also implement monitoring for unusual patterns of stream creation and reset activity to detect potential exploitation attempts before they cause significant impact.