CVE-2026-84304 in gRPC-Go
Summary
by MITRE • 09/01/2026
gRPC-Go is the Go language implementation of gRPC. Prior to 1.83.1, internal/transport/transport.go stores each fragmented HTTP/2 DATA frame as a separate recvMsg in recvBuffer, so millions of one-byte frames can consume disproportionate heap memory even when payload bytes remain within connection and stream flow-control windows. An unauthenticated remote attacker can use concurrent multiplexed streams to exhaust process memory and cause a runtime panic or out-of-memory termination. Receive-buffer compaction is enabled by default and can be controlled temporarily with GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION. This issue is fixed in version 1.83.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified in gRPC-Go, specifically within versions prior to 1.83.1, represents a significant resource exhaustion flaw rooted in the handling of HTTP/2 DATA frames during transport layer operations. As the official Go language implementation for the gRPC framework, this library is widely deployed across microservices architectures and distributed systems where high-throughput communication is critical. The core technical deficiency lies within the internal transport module, specifically in how fragmented data streams are processed. When an HTTP/2 connection receives DATA frames that have been split into smaller fragments due to network conditions or intentional fragmentation by a client, the library allocates a separate recvMsg structure for each individual fragment and stores it in the receive buffer. This design choice fails to account for scenarios where an attacker sends millions of one-byte frames concurrently across multiple multiplexed streams. Although these payloads may remain within the bounds defined by HTTP/2 connection-level and stream-level flow control windows, ensuring that the total volume of data is technically permissible under protocol specifications, the overhead associated with managing each individual message object becomes catastrophic. Each recvMsg structure carries significant metadata overhead relative to its tiny payload size, leading to disproportionate heap memory consumption that scales linearly with the number of fragments rather than the actual byte count of the transmitted data.
From an operational perspective, this flaw enables a remote unauthenticated attacker to execute a denial-of-service attack by deliberately exhausting the server process memory. By initiating numerous concurrent streams and sending highly fragmented DATA frames, the attacker forces the gRPC server to allocate vast amounts of heap space for message headers and internal bookkeeping structures. This rapid consumption of available memory eventually triggers a runtime panic or causes the operating system to terminate the process via an out-of-memory killer mechanism. The impact is severe as it disrupts service availability without requiring any form of authentication, making it particularly dangerous in public-facing services that accept gRPC traffic directly from untrusted networks. The attack vector relies on the ability to control fragmentation patterns and stream multiplexing rates, which are standard capabilities within HTTP/2 implementations but were not adequately mitigated against by default buffer management strategies in earlier versions of the library.
The resolution for this vulnerability was implemented in version 1.83.1 through the introduction of receive-buffer compaction mechanisms. This feature consolidates multiple small fragments into larger, more efficient memory blocks before they are processed as complete messages, thereby eliminating the overhead associated with managing millions of individual recvMsg objects. Administrators utilizing versions prior to this fix could temporarily mitigate the risk by enabling an experimental flag known as GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION, which activates a similar consolidation logic within the transport layer. However, relying on experimental flags is not recommended for production environments due to potential stability implications or performance variances. The definitive and secure approach requires upgrading to version 1.83.1 or later, where this compaction behavior is enabled by default, ensuring that memory usage remains proportional to actual data volume rather than fragment count.
This vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, as the application fails to properly limit the amount of resources consumed during normal operation under adversarial conditions. Furthermore, it maps to MITRE ATT&CK technique T1498, specifically Network Denial of Service via resource exhaustion through protocol abuse. The attack does not involve exploiting a logic error in authentication or authorization but rather abuses the fundamental mechanics of HTTP/2 multiplexing and fragmentation handling within the gRPC transport layer. Security practitioners should prioritize patching this vulnerability to prevent potential service disruptions caused by low-effort, high-impact memory exhaustion attacks. Regular monitoring of heap usage metrics during peak traffic periods can also serve as an early warning indicator for similar resource management issues in distributed systems relying on gRPC communications.