CVE-2026-84304: 
cAdvisor 脆弱性の分析と軽減

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. An unauthenticated remote attacker can send millions of tiny (e.g., 1-byte) HTTP/2 DATA frames across concurrent multiplexed streams, exhausting process heap memory and causing a runtime panic or out-of-memory (OOM) termination. All versions of google.golang.org/grpc up to and including 1.83.0 are affected; the issue is fixed in version 1.83.1. It carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory).

The root cause (CWE-400: Uncontrolled Resource Consumption) lies in internal/transport/transport.go, where each fragmented HTTP/2 DATA frame is stored as a separate recvMsg entry in the recvBuffer backlog. Because each recvMsg incurs its own struct and slice-header overhead (~56 bytes on 64-bit systems), millions of 1-byte frames cause heap memory consumption that is disproportionate to the actual payload volume — even when total payload bytes remain within configured HTTP/2 connection and stream flow-control windows. The attack requires no authentication and exploits HTTP/2 stream multiplexing to amplify the effect across many concurrent streams. The fix introduces a compactBacklogLocked() function that coalesces consecutive small data buffers into a single pooled buffer once overhead exceeds 50% of heap usage and a ~57 KB compaction threshold is crossed (GitHub Advisory, Fix PR #9331, Commit 7354d9c).

Successful exploitation results in a Denial of Service (DoS) — specifically a Go runtime panic or OOM termination of the affected gRPC-Go server process. There is no confidentiality or integrity impact; the vulnerability is limited to availability. Any service built on gRPC-Go versions ≤ 1.83.0 and exposed to untrusted network clients is at risk of complete service disruption, with no authentication barrier required for the attacker (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. NVD SSVC assessment classifies exploitation as "none" and automatable as "no", reflecting the current absence of active exploitation (GitHub Advisory). However, the attack requires no authentication and leverages standard HTTP/2 protocol mechanics, making it conceptually straightforward to implement.

1. Identify target: Locate internet-facing services using gRPC-Go versions ≤ 1.83.0 (e.g., via banner grabbing, service fingerprinting, or dependency scanning of open-source projects).
2. Establish HTTP/2 connection: Open an HTTP/2 connection to the target gRPC server. gRPC uses HTTP/2 by default, so standard HTTP/2 client libraries or tools (e.g., h2load, custom Go clients) can be used.
3. Open concurrent multiplexed streams: Initiate multiple concurrent gRPC streams over the same connection to maximize memory pressure across stream-level recvBuffer instances.
4. Send fragmented DATA frames: For each stream, transmit the payload fragmented into millions of 1-byte HTTP/2 DATA frames, keeping the total payload within the server's configured flow-control window to avoid triggering flow-control backpressure.
5. Exhaust heap memory: The server's recvBuffer accumulates a separate recvMsg entry per frame, each with ~56 bytes of overhead. With enough concurrent streams and frames, heap memory is exhausted, triggering a Go runtime panic or OOM kill of the server process (GitHub Advisory, Fix PR #9331).

• Network: Unusually high volume of HTTP/2 DATA frames from a single source IP with very small frame payloads (e.g., 1 byte per frame); abnormally large number of concurrent gRPC streams from a single client.
• Process: Sudden termination of the gRPC server process with a Go runtime panic message (e.g., runtime: out of memory) or OOM kill signal in system logs.
• Logs: Go runtime stack traces referencing internal/transport/transport.go or recvBuffer in crash dumps; kernel OOM killer logs (oom_kill_process) targeting the gRPC server process.
• System: Rapid increase in process heap memory consumption visible via monitoring tools (e.g., Prometheus Go runtime metrics go_memstats_heap_inuse_bytes) without a corresponding increase in legitimate request throughput.

Upgrade google.golang.org/grpc to version 1.83.1 or later, which includes the receive-buffer compaction fix by default (GitHub Advisory, Release v1.83.1). As a temporary workaround for deployments that cannot immediately upgrade, receive-buffer compaction is enabled by default in 1.83.1; if the feature causes unforeseen issues, it can be disabled via the environment variable GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION=false, though this re-exposes the vulnerability. Additionally, network-level controls such as rate-limiting HTTP/2 connections or restricting access to trusted clients can reduce exposure.