CVE-2023-33953: gRPC HPACK Parser DoS Vulnerability

CVE-2023-33953 Overview

CVE-2023-33953 is a denial of service vulnerability in gRPC, an open-source remote procedure call framework maintained by Google. The flaw resides in the HPACK header compression parser used by gRPC's HTTP/2 implementation. Three distinct attack vectors allow remote attackers to exhaust server memory and CPU resources without authentication. The vulnerability stems from HPACK table accounting errors and missing size enforcement in the parser code path. Successful exploitation causes unwanted disconnects between clients and servers, degrading availability for legitimate workloads. The issue affects multiple gRPC versions across language implementations that share the core HPACK parser.

Critical Impact

Unauthenticated remote attackers can trigger memory exhaustion and O(n²) CPU consumption against gRPC servers, causing service-wide denial of service.

Affected Products

• gRPC core library (grpc:grpc)
• gRPC implementations built on the affected core HPACK parser
• Services exposing gRPC endpoints over HTTP/2

Discovery Timeline

• 2023-08-09 - CVE-2023-33953 published to the National Vulnerability Database
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2023-33953

Vulnerability Analysis

The vulnerability is a Denial of Service flaw rooted in gRPC's HPACK parser, the component responsible for decoding HTTP/2 header blocks. Three independent defects combine to allow attacker-controlled resource exhaustion. The first defect is an unbounded memory buffering condition where the header size limit check runs after the string reading code. A client can send a string up to four gigabytes before the parser rejects it for exceeding the configured 8 KB or 16 KB limit.

The second defect involves HPACK variable-length integer encoding. The format permits an unlimited number of leading zero bytes prepended to an integer value. gRPC's parser reads every padding byte before completing the parse, allowing a client to force prolonged parsing of a single integer field.

The third defect targets metadata overflow checks. gRPC validated metadata size on a per-frame basis rather than across the full header block. An attacker can split header content across a HEADERS frame followed by an arbitrary chain of CONTINUATION frames, bypassing the overflow guard and forcing the server to buffer unbounded header data.

Root Cause

The underlying weaknesses map to [CWE-789] Memory Allocation with Excessive Size Value and [CWE-770] Allocation of Resources Without Limits or Throttling. A per-input-block memory copy inside the HPACK parser, combined with the unbounded string read, produces an O(n²) parsing loop where the attacker controls n.

Attack Vector

An unauthenticated remote attacker establishes an HTTP/2 connection to a vulnerable gRPC server. The attacker sends crafted HPACK-encoded headers that exploit one or more of the three defects: an oversized header string, a varint padded with zero bytes, or a long chain of CONTINUATION frames carrying metadata. The server buffers attacker-controlled data and executes redundant memory copies, exhausting memory or CPU and denying service to legitimate clients.

No proof-of-concept code has been published for this issue. Refer to the Google Cloud Security Bulletin for vendor technical details.

Detection Methods for CVE-2023-33953

Indicators of Compromise

• Sudden spikes in memory or CPU utilization on gRPC server processes without a corresponding increase in legitimate request volume
• HTTP/2 connections sending unusually large HEADERS or extended chains of CONTINUATION frames from a single client
• Repeated client disconnects logged by gRPC servers with HPACK decoding errors

Detection Strategies

• Inspect HTTP/2 traffic at the application gateway for header blocks exceeding configured size limits before they reach gRPC backends
• Alert on gRPC server logs containing HPACK parse failures, oversized metadata errors, or repeated RST_STREAM events from the same peer
• Correlate process-level CPU saturation with active gRPC connection counts to surface algorithmic complexity abuse

Monitoring Recommendations

• Track gRPC server metrics for header block size distributions and parse latency per connection
• Enable connection-level rate limiting telemetry and forward HTTP/2 frame counters to a central log pipeline
• Monitor sustained outbound GOAWAY frames issued by gRPC servers, which often indicate parser-driven disconnects

How to Mitigate CVE-2023-33953

Immediate Actions Required

• Upgrade gRPC to a fixed release as identified in the Google Cloud Security Bulletin GCP-2023-022
• Inventory all services that link against the gRPC core library, including language bindings such as gRPC C++, Python, Ruby, and PHP
• Place gRPC endpoints behind an HTTP/2-aware proxy that enforces strict header size and frame count limits

Patch Information

The gRPC maintainers released updated versions that enforce header size checks before string buffering, cap leading-zero bytes in HPACK varints, and apply metadata overflow checks across the full header block including CONTINUATION frames. Consult the Google Cloud Security Bulletin for the specific fixed versions corresponding to each gRPC language binding.

Workarounds

• Terminate HTTP/2 at a reverse proxy that enforces conservative MAX_HEADER_LIST_SIZE and CONTINUATION frame limits ahead of gRPC backends
• Apply network-level rate limiting and per-client connection caps to reduce blast radius from a single abusive peer
• Restrict gRPC endpoints to authenticated peers via mutual TLS where the service model permits

# Configuration example: enforce HTTP/2 header limits at an Envoy front proxy
# placed in front of gRPC backends until the underlying library is patched.
static_resources:
  listeners:
  - name: grpc_listener
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          max_request_headers_kb: 16
          common_http_protocol_options:
            max_headers_count: 100
            max_stream_duration: 30s
          http2_protocol_options:
            max_concurrent_streams: 100
            initial_stream_window_size: 65536
            initial_connection_window_size: 1048576