Paulo Valente

**Name of the Vulnerable Software and Affected Versions** elixir-grpc versions 0.8.0 through 0.9.x **Description** 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. **Recommendations** Update to version 1.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** grpc versions 0.3.1 through 0.9.x **Description** 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. **Recommendations** Update to version 1.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** elixir-grpc versions 0.4.0 through 0.9.x **Description** 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`. **Recommendations** Update to version 1.0.0 or later.

**Name of the Vulnerable Software and Affected Versions** grpc versions 0.4.0 through 0.9.x **Description** 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. **Recommendations** Update to version 1.0.0 or later. As a temporary workaround, avoid registering `GRPC.Codec.Erlpack` as a codec on the gRPC server.