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. In internal/transport/transport.go, each fragmented DATA frame is stored 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. It affects all versions of google.golang.org/grpc up to and including 1.83.0, and is fixed in version 1.83.1. The vulnerability was published on September 1, 2026, with a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-400 (Uncontrolled Resource Consumption). In the vulnerable code path, recvBuffer.put() in internal/transport/transport.go appends each incoming HTTP/2 DATA frame as an independent recvMsg struct to a backlog slice, regardless of frame size. Because each recvMsg incurs fixed memory overhead for internal tracking structures and queue allocation (approximately 56 bytes per struct on 64-bit systems), an attacker who fragments a payload into millions of 1-byte frames can cause the per-frame overhead to vastly exceed the actual payload data — all while staying within HTTP/2 flow-control limits. By multiplexing multiple concurrent gRPC streams, an unauthenticated remote attacker can amplify this effect to exhaust the Go runtime heap, triggering a runtime panic or out-of-memory (OOM) termination. 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 compaction threshold (~57 KB / ~1024 messages) is reached (GitHub Advisory, Fix PR #9331, Commit 7354d9c).

Successful exploitation results in a complete denial of service for the affected gRPC-Go server process — either a Go runtime panic or an out-of-memory termination. There is no confidentiality or integrity impact; the vulnerability is purely an availability issue. Any service built on gRPC-Go versions ≤ 1.83.0 that accepts inbound gRPC connections (including from unauthenticated clients) is at risk, and a single attacker using concurrent multiplexed streams can bring down the entire process (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (Feedly). The NVD SSVC assessment classifies exploitation as "none" and the attack as not automatable. The EPSS score is approximately 0.415%, indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Identify target: Locate internet-facing services running gRPC-Go versions ≤ 1.83.0 using network scanning tools (e.g., Shodan, Censys) or by inspecting Go module dependencies (go.mod) in open-source projects.
2. Establish gRPC connection: Open a gRPC connection to the target server. No authentication is required — the attack works against any publicly accessible gRPC endpoint.
3. Open multiple concurrent streams: Using HTTP/2 multiplexing, open as many concurrent gRPC streams as the server's MaxConcurrentStreams setting allows.
4. Fragment payload into tiny DATA frames: For each stream, send the gRPC payload fragmented into millions of 1-byte (or similarly tiny) HTTP/2 DATA frames. Ensure the total payload volume stays within the configured connection and stream flow-control windows to avoid triggering flow-control backpressure.
5. Exhaust heap memory: The server's recvBuffer accumulates a separate recvMsg struct for each tiny frame, inflating heap usage far beyond the actual payload size. Repeating this across multiple concurrent streams rapidly exhausts available process memory.
6. Trigger OOM/panic: Once heap memory is exhausted, the Go runtime triggers an out-of-memory termination or runtime panic, crashing the gRPC server process and achieving denial of service (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 source IP or a small set of IPs; abnormally high number of concurrent HTTP/2 streams from a single client.
• Process: Rapid, sustained growth in Go process heap memory (/proc/<pid>/status showing VmRSS or VmHeap climbing continuously); Go runtime OOM killer messages or panic stack traces in process logs referencing runtime: out of memory or fatal error: runtime: out of memory.
• Logs: gRPC server logs showing a large number of concurrent active streams; Go runtime panic output with stack traces originating from internal/transport/transport.go recvBuffer.put() or related functions; sudden process restart events in service managers (systemd, Kubernetes pod restarts).
• System: OS-level OOM killer events in /var/log/syslog or dmesg referencing the gRPC server process; unexpected process crashes or container restarts correlated with high inbound network traffic.

Upgrade google.golang.org/grpc to version 1.83.1 or later, which includes the receive-buffer compaction fix that coalesces small DATA frames into pooled buffers, eliminating the disproportionate memory overhead (GitHub Advisory, Release v1.83.1). As a temporary workaround for deployments that cannot immediately upgrade, receive-buffer compaction is enabled by default in v1.83.1; if you have explicitly disabled it, ensure the environment variable GRPC_GO_EXPERIMENTAL_ENABLE_RECEIVE_BUFFER_COMPACTION is set to true (or left unset). Note that setting this variable to false re-exposes the vulnerability and should be avoided. 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 (Fix PR #9331).

The fix was merged by contributor arjan-bal and reviewed by easwars on August 19, 2026, and cherry-picked to the v1.83.x release branch the same day (Fix PR #9331, Cherry-pick PR #9333). The vulnerability was picked up by downstream package maintainers quickly, with multiple open-source projects (Forgejo, LycheeOrg, gin-gonic examples, SolarWinds APM) opening automated dependency update PRs to bump to v1.83.1 within days of disclosure. Microsoft included the CVE in its September 2026 Patch Tuesday advisory, and SUSE and openSUSE issued security announcements for affected packages (BleepingComputer).