-
CVSS Score
-Basic Information
CVE ID
-
GHSA ID
-
EPSS Score
-
CWE
-
Published
-
Updated
-
KEV Status
-
Technology
-
Technical Details
Vulnerability Intelligence
Miggo AI
Miggo AIMiggo AI| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| google.golang.org/grpc | go | < 1.56.3 | 1.56.3 |
| google.golang.org/grpc | go | >= 1.57.0, < 1.57.1 | 1.57.1 |
| google.golang.org/grpc | go | >= 1.58.0, < 1.58.3 | 1.58.3 |
Miggo AIRoot Cause AnalysisThe vulnerability (GHSA-m425-mq94-257g / CVE-2023-44487) allowed an attacker to cause the gRPC-Go server to launch more concurrent method handlers than the configured maximum stream limit by sending HTTP/2 requests and then canceling them rapidly. The analysis of the patch commit f2180b4d5403d2210b30b93098eb7da31c05c721 reveals that the core issue was in the server.go file.
The (*Server).serveStreams method is responsible for managing incoming streams and dispatching them. Before the patch, its mechanism for launching stream handlers (which execute (*Server).handleStream) did not robustly enforce the s.opts.maxConcurrentStreams limit under the described rapid reset scenario. The patch introduced an atomicSemaphore (named streamQuota) within serveStreams. This semaphore's acquire() method is now called before any new stream handler (a function wrapping handleStream) is started, ensuring the concurrency limit is respected.
Thus, (*Server).serveStreams contained the control flow vulnerability. (*Server).handleStream is the function that executes the actual stream processing and was being invoked excessively due to the flaw in serveStreams. Both are critical to understanding the vulnerability and its exploitation profile.
Changes in internal/transport/http2_server.go primarily ensure that the MaxConcurrentStreams setting is correctly communicated at the HTTP/2 protocol level, but the server's internal enforcement of this limit, which was the site of the vulnerability, resides in server.go.
GoGoOngoing coverage of React2Shell