Uncaught exception in Google gRPC TCP server enables denial of service

Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.

• Google gRPC on POSIX-compatible platforms: versions 1.53.0 through 1.53.1 are affected; the corresponding fix is 1.53.2.
• Google gRPC on POSIX-compatible platforms: versions 1.54.0 through 1.54.2 are affected; the corresponding fix is 1.54.3.
• Google gRPC on POSIX-compatible platforms: versions 1.55.0 through 1.55.2 are affected; the corresponding fix is 1.55.3.
• Google gRPC on POSIX-compatible platforms: versions 1.56.0 through 1.56.1 are affected; the corresponding fix is 1.56.2.
• The GitHub Advisory Database maps the four ranges above to the RubyGems grpc package. For the Python grpcio package, that advisory lists affected 1.53.x, 1.54.x, and 1.55.x branches with the corresponding fixes; the status of another Python branch should not be inferred.
• The upstream CVE data returned during research lists versions before 1.23 and version 1.57 as unaffected. The status of parallel or unlisted branches is not established by this evidence.

The flaw is in the gRPC Core TCP server on POSIX-compatible platforms such as Linux. When an attacker actively creates a large number of connections, the server may encounter file descriptor exhaustion or fail to handle the resulting error condition, causing service degradation or loss of availability. The weakness is classified as CWE-248, involving an exception or error that is not handled correctly. The upstream fix work focuses on improving server handling when file descriptors are exhausted. The exact exception, triggering threshold, and detailed execution path are not established by the available evidence.

The attack is network reachable against an exposed gRPC TCP server. The supplied attack properties indicate that authentication is not required, no user interaction is required, and the attack condition is relatively simple to reach. The attacker must create a significant number of connections; the exact threshold is not established. The record marks public exploit as false, but it does not provide a complete current conclusion about real-world exploitation and does not identify a campaign, victim, or specific exploit.

A remote attacker can disrupt a gRPC TCP server by creating many connections, potentially exhausting resources and causing denial of service. The record does not establish a change in privilege or security scope. It does not establish code execution, data access, data modification, or privilege escalation. Organisationally, APIs or backend services that depend on the affected server may become unavailable, but the extent of disruption depends on the deployment architecture and failure isolation.

The flaw can reduce or eliminate the availability of gRPC TCP services when the server must process a large volume of connections.

• APIs, workers, or services that depend on gRPC may experience interruption, increased latency, or restarts.
• The primary business consequence is reduced service availability and capacity.
• The available evidence does not indicate that the flaw enables data disclosure, data modification, or unauthorized access.
• Actual severity depends on whether the endpoint is exposed, how connection resources are controlled, and how the service recovers.

1. Upgrade each affected branch to its corresponding fixed release: 1.53.2, 1.54.3, 1.55.3, or 1.56.2. Do not replace branch-specific guidance with an assumption that every later release has been verified.
2. For Python grpcio, use the corresponding fixed releases 1.53.2, 1.54.3, or 1.55.3 when the dependency falls within the branches listed by the advisory.
3. For RubyGems grpc, verify the package in use and upgrade out of the affected ranges to the corresponding fixed release.
4. Review transitive dependencies so applications that do not use gRPC directly are not missed when they package a vulnerable gRPC library.
5. If an upgrade cannot be completed immediately, apply a vendor-confirmed mitigation. The available record does not provide a confirmed workaround; connection limits or reduced network exposure should be treated only as temporary defense in depth, not as a fix.

1. Inventory services using gRPC C++, Python, or Ruby, including direct and transitive dependencies.
2. Check the deployed package or library version and compare it with each affected branch listed below.
3. Identify gRPC TCP servers running on POSIX-compatible platforms and listeners reachable from untrusted networks.
4. Review logs, metrics, and operational alerts for connection bursts, file descriptor exhaustion, resource errors, or server restarts. These are precautionary monitoring signals, not confirmed indicators of compromise.
5. Do not treat the absence of these signals as proof of safety because the condition may not have been triggered or telemetry may be incomplete.