EEF-CVE-2026-121808: Memory exhaustion via compressed Erlang terms in the elixir-grpc Erlpack codec

Summary

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpccore and grpc allows unauthenticated attackers to exhaust server memory via a compressed Erlang external term in a gRPC message body.

GRPC.Codec.Erlpack.decode/2 (grpccore/lib/grpc/codec/erlpack.ex, and lib/grpc/codec/erlpack.ex before the package split) passes the message body to :erlang.binarytoterm/2. That function inflates a compressed term in full before it returns. The codec sets no limit on the decoded size, and its type checks run only on the decoded term. The server's maxbodysize limit counts the compressed bytes of the request. A request with Content-Type: application/grpc+erlpack can therefore make the server allocate a term much larger than the request body.

This issue affects grpc: from 0.4.0 before 1.0.0; grpccore: from 1.0.0 before 1.1.0.

Details

1. Codec selection

The server selects the codec from the request Content-Type. application/grpc+erlpack selects GRPC.Codec.Erlpack when the server registers it. No authentication step comes before this.

2. Size limit on compressed bytes only

The server limits the request body with maxbodysize, which counts the bytes received. With the gRPC compressed flag set to 0, the transport decompression limit does not apply, and the message reaches the codec unchanged.

3. Expansion inside binarytoterm/2

GRPC.Codec.Erlpack.decode/2 calls :erlang.binarytoterm(binary, [:safe]). The Erlang external term format has a compressed form (version byte 131, tag 80, a 32-bit uncompressed size, then a zlib stream). binarytoterm/2 inflates it in full, and the :safe option does not limit the size. ensuresafeterm!/1 runs after the call returns and accepts a large binary.

4. Result

In a test against grpcserver 1.0.6, a 260,932-byte request body decoded to a 268,435,456-byte binary, which the server passed to the application callback.

Proof of concept

1. Start a gRPC server that registers GRPC.Codec.Erlpack in its codecs list. 2. Build the payload with :erlang.termtobinary(:binary.copy(<<0>>, 268435456), [:compressed]). The result is 260,932 bytes. 3. Send the payload as one uncompressed gRPC message (compressed flag 0) to any method of the server, with Content-Type: application/grpc+erlpack. 4. Observe that the server allocates the 268,435,456-byte binary and passes it to the application callback.

Impact

An unauthenticated client can make a server that registers the Erlpack codec allocate memory far beyond the size of the request with one request. Memory exhaustion affects every service on that node.

Workarounds

Remove GRPC.Codec.Erlpack from the server's codecs list if the codec is not needed.

If the codec is needed, register a wrapper codec in its place. The wrapper implements the GRPC.Codec behaviour, returns "erlpack" from name/0, raises in decode/2 when the body starts with the bytes 131, 80 (the compressed term tag), and delegates all other calls to GRPC.Codec.Erlpack.

Configurations

GRPC.Codec.Erlpack must be explicitly registered as a codec on the gRPC server.