Paulo Valente

An unauthenticated attacker can cause memory exhaustion and crash the node by sending an oversized request body via client-streaming or bidirectional-streaming. The issue occurs because the streaming read path in `Elixir.GRPC.Server.Adapters.Cowboy.Handler`:info/3 does not enforce the `max body size` limit, unlike the unary read path. Specifically, `Elixir.GRPC.Server.Adapters.Cowboy`:reading stream/1 appends received chunks to a buffer until a complete length-prefixed message is formed. By declaring a very large message and sending it through multiple small HTTP/2 DATA frames, an attacker can force the buffer to grow without limit, leading to a BEAM memory exhaustion and a complete node crash.

Authenticated attackers can access or modify resources belonging to other users by smuggling a conflicting value for any path-bound field via the query string or request body. This occurs in the `map request/5` function within `Elixir.GRPC.Server.Transcode` (lib/grpc/server/transcode.ex), where `Map.merge/2` is used with path bindings as the first argument, granting them the lowest merge precedence. Consequently, a request such as 'GET /users/me/profile?user id=victim' or a POST request containing `user id` in the body results in a decoded protobuf struct where the path-bound field is overwritten by the attacker-supplied value. This allows the bypass of handlers using these fields for authorization, ownership checks, or multi-tenancy scoping. This issue requires HTTP-to-gRPC transcoding to be enabled.

Unauthenticated attackers can exhaust the BEAM memory and crash the server by streaming a large or slow-trickle unary request body. The function `read full body/3` in 'Elixir.GRPC.Server.Adapters.Cowboy.Handler' accumulates every received chunk into a single growing binary without a size cap. Furthermore, if the client omits the `grpc-timeout` header, the per-chunk read timeout is set to infinity, enabling a slow-trickle client to maintain the connection indefinitely while memory consumption increases. A single connection is enough to exhaust server memory and crash the node.

Improper handling of highly compressed data in the `GRPC.Compressor.Gzip` and `GRPC.Message` modules allows a denial of service via a gzip decompression bomb. The function `decompress/1` in `Elixir.GRPC.Compressor.Gzip` calls `:zlib.gunzip/1` on attacker-controlled bytes without a decompressed-size limit, ratio check, or incremental decoding. This occurs automatically when an incoming gRPC frame contains the `grpc-encoding: gzip` header. Since `:zlib.gunzip/1` allocates the entire decompressed result as a single binary, a small, highly compressible payload can expand to multiple gigabytes, exhausting the BEAM node's heap and triggering an out-of-memory kill. The `max receive message length` limit is ineffective as it is only enforced after decompression. This can be exploited by an unauthenticated remote peer using the `from data/2` function in `Elixir.GRPC.Message`.

Deserialization of untrusted data and allocation of resources without limits or throttling allow unauthenticated attackers to crash the BEAM node or achieve remote code execution on the server. The function `decode/2` in `Elixir.GRPC.Codec.Erlpack` calls `:erlang.binary to term/1` on the raw gRPC message body without the `:safe` option, size bounds, or type guards. An unauthenticated peer sending a request with `Content-Type: application/grpc+erlpack` can provide a crafted payload to mint arbitrary new atoms, which are not garbage-collected, leading to atom table exhaustion and a VM crash. Additionally, the payload can encode a fun term that executes attacker-controlled code if applied downstream. This issue occurs when `GRPC.Codec.Erlpack` is explicitly registered as a codec on the gRPC server.