CVE-2026-53430: elixir-grpc Gzip Decompression DoS Attack

CVE-2026-53430 Overview

CVE-2026-53430 is a denial-of-service vulnerability in the elixir-grpc/grpc library affecting versions 0.4.0 through 1.0.0. The flaw resides in the GRPC.Compressor.Gzip and GRPC.Message modules, which decompress incoming gRPC frames without enforcing any size or ratio limits. An unauthenticated remote attacker can send a single gzip-compressed frame that expands to multiple gigabytes, exhausting the BEAM virtual machine heap and triggering an out-of-memory kill.

Critical Impact
A single crafted gRPC frame can crash the entire Erlang/Elixir node by exhausting memory, taking down all hosted services without authentication.

Affected Products

elixir-grpc/grpc versions 0.4.0 through 0.x (prior to 1.0.0)
Elixir applications using GRPC.Compressor.Gzip for gRPC message handling
BEAM-based services accepting gRPC traffic with grpc-encoding: gzip

Discovery Timeline

2026-06-15 - CVE-2026-53430 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-53430

Vulnerability Analysis

The vulnerability is classified as Improper Handling of Highly Compressed Data, also known as a decompression bomb [CWE-409]. The function 'Elixir.GRPC.Compressor.Gzip':decompress/1 calls :zlib.gunzip/1 directly on attacker-controlled bytes. The call performs no decompressed-size check, ratio validation, or incremental decoding.

Because GRPC.Compressor.Gzip is the registered gzip compressor implementation, the library invokes it automatically when an inbound frame carries the grpc-encoding: gzip header. The :zlib.gunzip/1 function allocates the full decompressed payload as a single binary on the BEAM heap.

Gzip compresses repetitive content such as null bytes at ratios approaching 1000:1. A few kilobytes of compressed input therefore expand to multiple gigabytes in one allocation, triggering an out-of-memory kill of the BEAM node.

Root Cause

The max_receive_message_length setting is enforced only against the already-decompressed message in 'Elixir.GRPC.Message':from_data/2. This check runs after :zlib.gunzip/1 returns, so it provides no protection against memory exhaustion during decompression itself.

Attack Vector

The attack requires no authentication, no user interaction, and only network access to a gRPC endpoint that accepts gzip-encoded requests. The attacker sends a single HTTP/2 frame containing a small, highly compressible gzip payload along with the grpc-encoding: gzip header.

text

 defmodule GRPC.Compressor.Gzip do
   @behaviour GRPC.Compressor
 
+  # 4 MB – matches gRPC-Go's default max receive message size.
+  # Override with: Application.put_env(:grpc, :max_decompressed_message_length, bytes)
+  @default_max_decompressed_size 4 * 1024 * 1024
+
+  # Feed compressed input in 8 KB slices so we can detect an oversized output
+  # before allocating the full decompressed payload.
+  @input_chunk_size 8_192
+
   def name do
     "gzip"
   end

Source: GitHub commit 1afbab9. The patch introduces a default 4 MB decompressed-size cap and streams input in 8 KB chunks so oversized output is detected before full allocation.

Detection Methods for CVE-2026-53430

Indicators of Compromise

Sudden BEAM virtual machine termination with out-of-memory errors in service logs.
Spikes in resident memory followed by process restarts on hosts running Elixir gRPC services.
Inbound gRPC requests with grpc-encoding: gzip and unusually small compressed payloads followed by node crashes.
Repeated client disconnections coinciding with memory exhaustion events.

Detection Strategies

Inspect HTTP/2 traffic for gRPC frames whose advertised or actual decompressed size greatly exceeds the compressed payload size.
Alert on compression ratios above 100:1 at gRPC ingress points or reverse proxies.
Correlate kernel oom-killer events with the parent BEAM process identifier to confirm decompression-driven exhaustion.

Monitoring Recommendations

Track BEAM process memory using :erlang.memory/0 and emit metrics to your observability backend.
Log every invocation of GRPC.Compressor.Gzip.decompress/1 along with input and output sizes for auditing.
Configure alerts on rapid heap growth in gRPC service pods or VMs, especially on unauthenticated endpoints.

How to Mitigate CVE-2026-53430

Immediate Actions Required

Upgrade elixir-grpc/grpc to version 1.0.0 or later, which contains the streaming decompression fix.
If immediate upgrade is not possible, disable gzip compression support on gRPC endpoints by removing gzip from the accepted encodings.
Place a reverse proxy in front of gRPC services to reject requests with abnormal compression ratios.
Restrict network exposure of gRPC endpoints to trusted clients until the patch is applied.

Patch Information

The fix is delivered in commit 1afbab9d57d2a3e16ca9c62ffa4923338ea96cfc and released in grpc1.0.0. Review the GitHub Security Advisory GHSA-6ccx-9c9f-327w and the CNA report for full details.

Workarounds

Set a low max_decompressed_message_length via Application.put_env(:grpc, :max_decompressed_message_length, bytes) after upgrading.
Strip the grpc-encoding: gzip header at a gateway layer when clients are not required to use compression.
Enforce per-connection memory and rate limits at the load balancer or service mesh to contain abusive peers.

bash

# Pin the patched version in mix.exs
# {:grpc, "~> 1.0.0"}
mix deps.update grpc

# Optional: lower the decompressed size cap to 1 MB at runtime
# config/runtime.exs
# config :grpc, max_decompressed_message_length: 1 * 1024 * 1024