CVE-2026-84304: 
cAdvisor vulnerability analysis and mitigation

CVE-2026-84304 is a heap memory exhaustion vulnerability in gRPC-Go (the Go language implementation of gRPC) caused by improper handling of fragmented HTTP/2 DATA frames. Prior to version 1.83.1, internal/transport/transport.go stored each fragmented HTTP/2 DATA frame as a separate recvMsg in recvBuffer, allowing millions of tiny (e.g., 1-byte) frames to consume disproportionate heap memory even when total payload bytes remain within configured flow-control windows. The vulnerability affects all gRPC-Go versions up to and including 1.83.0 and was disclosed on September 1, 2026. It carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption). The vulnerable code in internal/transport/transport.go allocates a separate recvMsg struct for every HTTP/2 DATA frame fragment received, regardless of payload size. Each recvMsg incurs fixed memory overhead for internal tracking structures and queue allocation (~56 bytes per message on 64-bit systems), meaning an attacker sending millions of 1-byte frames can cause heap usage to grow at a ratio far exceeding the actual payload data — even while staying within HTTP/2 flow-control window limits. The attack requires no authentication and exploits HTTP/2's native stream multiplexing to amplify the effect across concurrent streams. The fix introduces a compactBacklogLocked() function that coalesces consecutive small data buffers into larger pooled buffers once overhead exceeds 50% of heap usage, controlled by the GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION environment variable (GitHub Advisory, Fix PR #9331).

Successful exploitation results in a Denial of Service (DoS) condition — specifically a Go runtime panic or out-of-memory (OOM) termination of the affected gRPC-Go server process. There is no confidentiality or integrity impact; the vulnerability is purely an availability concern. Any service or application embedding gRPC-Go versions ≤ 1.83.0 as a server-side component is at risk, including widely deployed infrastructure tools such as Kubernetes components, Helm, Docker (Moby), Azure Storage AzCopy, and other Go-based microservices that depend on google.golang.org/grpc (GitHub Advisory, Fix PR #9331).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.415%, indicating a low probability of exploitation in the near term. The attack is network-accessible, requires no authentication or user interaction, and has low attack complexity — making it theoretically straightforward to exploit against exposed gRPC endpoints, though no weaponized tooling has been observed.

1. Reconnaissance: Identify internet-facing or network-accessible services running gRPC-Go versions ≤ 1.83.0. Tools such as Shodan, Censys, or grpc_cli can be used to enumerate gRPC endpoints.
2. Establish gRPC connection: Connect to the target gRPC server and initiate one or more streaming RPC calls using any available service method that accepts a request body.
3. Fragment payload into tiny HTTP/2 DATA frames: Using a custom HTTP/2 client or a modified gRPC client library, send the request payload split into millions of 1-byte HTTP/2 DATA frames instead of a single frame. Ensure the total payload volume stays within the server's configured flow-control window to avoid triggering standard flow-control rejection.
4. Multiplex concurrent streams: Open multiple concurrent gRPC streams simultaneously, each sending fragmented frames, to amplify heap memory consumption across streams.
5. Exhaust server heap memory: As the server allocates a separate recvMsg struct per frame, heap usage grows rapidly. With sufficient concurrent streams and frame volume, the Go runtime will trigger an out-of-memory panic, crashing the gRPC server process (GitHub Advisory, Fix PR #9331).

• Network: Unusually high volume of small HTTP/2 DATA frames (e.g., 1-byte payloads) on gRPC ports (typically TCP 443 or 50051) from a single or small set of source IPs; abnormally high number of concurrent open HTTP/2 streams from a single client.
• Process/Runtime: Go runtime panic logs containing runtime: out of memory or fatal error: runtime: out of memory; sudden termination of the gRPC server process with a non-zero exit code.
• Logs: Application logs showing a spike in incoming stream counts without corresponding increase in processed RPC completions; gRPC server logs indicating connection resets or stream errors immediately before process crash.
• System: Rapid increase in process heap memory consumption (observable via pprof, top, or container memory metrics) without a corresponding increase in legitimate request throughput; OOM killer events in Linux kernel logs (dmesg) targeting the gRPC server process.

Upgrade google.golang.org/grpc to version 1.83.1 or later, which includes the receive-buffer compaction fix (commits 7354d9c and 8cfeca0). As a temporary workaround prior to upgrading, receive-buffer compaction is enabled by default in v1.83.1 and can be disabled via GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION=false if it causes unforeseen issues (this escape hatch will be removed in a future release). Network-level controls such as rate-limiting concurrent gRPC streams or restricting access to gRPC endpoints to trusted clients can reduce exposure but do not fully remediate the vulnerability (GitHub Advisory, Fix PR #9331).

The vulnerability was picked up broadly across the Go ecosystem, with numerous downstream projects — including Docker (Moby), Kubernetes, Helm, Azure Storage AzCopy, New Relic Infrastructure Agent, and CircleCI — issuing dependency updates to gRPC-Go v1.83.1 shortly after disclosure. SUSE issued multiple security advisories (SUSE-SU-2026:4062-1, SUSE-SU-2026:4125-1, SUSE-SU-2026:4175-1, SUSE-SU-2026:4178-1) covering affected packages, and openSUSE published corresponding security announcements. Microsoft included the CVE in its September 2026 Patch Tuesday coverage, which was reported by BleepingComputer (BleepingComputer). The VulnDB community and infosec social media (Mastodon/infosec.exchange) noted the advisory shortly after publication.