CVE-2026-121809: CPU exhaustion via a truncated gRPC message on streaming RPCs in elixir-grpc grpc_server

Summary

Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in elixir-grpc grpcserver and grpc allows unauthenticated attackers to occupy a BEAM scheduler indefinitely via a client-streaming or bidirectional-streaming request whose body ends inside a gRPC message.

GRPC.Server.Adapters.Cowboy.readstream/1 (grpcserver/lib/grpc/server/adapters/cowboy.ex, and the Cowboy adapter in grpc before the package split) asks for more data whenever the buffer does not hold a complete message. Once the request body has ended, every further read returns an empty chunk, so the buffer never changes and the function retries without end. A single 5-byte length prefix sent with ENDSTREAM keeps one scheduler busy for as long as the connection stays open, and repeated requests exhaust all schedulers.

This issue affects grpcserver: from 1.0.0 before 1.1.0; grpc: from 0.3.1 before 1.0.0.

Details

1. A partial message

A client sends a 5-byte gRPC length prefix that declares more bytes than follow it, and ends the request body with ENDSTREAM.

2. The reader asks for more

readstream/1 calls GRPC.Message.getmessage/1, which returns false because the declared message is incomplete. readstream/1 then sets needmore and reads again through Handler.readbody/1.

3. Every read is empty

Once the body has been read, the handler's asyncreadbody/2 (and cowboyreq:readbody/2 in older releases) returns an empty chunk at once. The buffer stays the same, the exit clause for an empty finished buffer never matches, and the loop repeats.

4. No timeout ends it

Each iteration is a message round trip between two local processes, not a socket wait, so no I/O timeout applies. Without a grpc-timeout header there is no deadline, and the adapter's idle timeout defaults to :infinity. One scheduler stays at full load until the client closes the connection.

Proof of concept

1. Start a server that exposes a client-streaming RPC, for example RouteGuide.RecordRoute. 2. Open an HTTP/2 connection and send HEADERS for that method with content-type: application/grpc and no grpc-timeout. 3. Send one DATA frame with ENDSTREAM that holds only the 5-byte prefix 00 00 00 00 64, which declares a 100-byte message. 4. Keep the connection open and observe that no response arrives and one BEAM scheduler stays at 100% CPU until the connection closes.

Impact

An unauthenticated client can keep one scheduler busy per open connection with a 5-byte request, and enough connections deny service to every application on the node.

Configurations

The server must expose at least one client-streaming or bidirectional-streaming RPC method.