Elixir Grpc Grpc
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in Elixir Grpc Grpc.
By the Year
In 2026 there have been 4 vulnerabilities in Elixir Grpc Grpc.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 4 | 0.00 |
It may take a day or so for new Grpc vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Elixir Grpc Grpc Security Vulnerabilities
Deserialization & Atom Exhaustion in Elixir.GRPC 0.4-<1.0 via erlpack
CVE-2026-48853
- June 15, 2026
Deserialization of Untrusted Data and Allocation of Resources Without Limits or Throttling vulnerabilities in elixir-grpc grpc allow unauthenticated attackers to crash the BEAM node via atom table exhaustion and, when a decoded term flows into a call site that invokes it, achieve remote code execution on the server. 'Elixir.GRPC.Codec.Erlpack':decode/2 (lib/grpc/codec/erlpack.ex) calls :erlang.binary_to_term/1 on the raw gRPC message body without the :safe option, no size bound, and no type guard. Any unauthenticated peer that sends a request with Content-Type: application/grpc+erlpack can send a crafted payload that mints arbitrary new atoms (which are never garbage-collected, exhausting the bounded atom table and crashing the VM) or that encodes a fun term which, if applied anywhere downstream, executes attacker-controlled code inside the server process. This issue affects grpc from 0.4.0 before 1.0.0.
Marshaling, Unmarshaling
elixir-grpc 0.4.0<1.0.0: gzip Decompression Bomb DoS
CVE-2026-53430
- June 15, 2026
Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in elixir-grpc grpc (GRPC.Compressor.Gzip, GRPC.Message modules) allows a denial of service via a gzip decompression bomb. This vulnerability is associated with program files lib/grpc/compressor/gzip.ex, lib/grpc/message.ex and program routines 'Elixir.GRPC.Compressor.Gzip':decompress/1, 'Elixir.GRPC.Message':from_data/2. 'Elixir.GRPC.Compressor.Gzip':decompress/1 calls :zlib.gunzip/1 directly on attacker-controlled bytes with no decompressed-size limit, ratio check, or incremental decoding. Because this module is the registered gzip GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries the grpc-encoding: gzip header. :zlib.gunzip/1 allocates the entire decompressed result as a single binary, so a small highly compressible payload (for example a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single call. The max_receive_message_length limit is enforced only against the already-decompressed message, so it provides no protection. An unauthenticated remote peer can send a single crafted frame to exhaust the BEAM node's heap and trigger an out-of-memory kill. This issue affects grpc: from 0.4.0 before 1.0.0.
Data Amplification
elixir-grpc 0.8-1.0 Auth Bypass via User-Controlled Key in Path Binding
CVE-2026-48599
- June 15, 2026
Authorization Bypass Through User-Controlled Key vulnerability in elixir-grpc grpc allows authenticated attackers to 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. In 'Elixir.GRPC.Server.Transcode':map_request/5 (lib/grpc/server/transcode.ex), all three clauses use Map.merge/2 with path bindings as the first argument, giving them the lowest merge precedence. A request such as GET /users/me/profile?user_id=victim (or a POST with {"user_id": "victim"} when body: "*") yields a decoded protobuf struct where the path-bound field carries the attacker-supplied value rather than the router-extracted value. Any handler that uses the path-bound field for authorization, multi-tenancy scoping, or ownership checks is silently bypassed. This issue affects grpc from 0.8.0 before 1.0.0.
Insecure Direct Object Reference / IDOR
Elixir GRPC pre-1.0.0: Unbounded Memory Allocation via Streaming RPCs
CVE-2026-48854
- June 15, 2026
Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpc allows unauthenticated attackers to exhaust the BEAM's memory and crash the server by streaming a large or slow-trickle unary request body. 'Elixir.GRPC.Server.Adapters.Cowboy.Handler':read_full_body/3 (lib/grpc/server/adapters/cowboy/handler.ex) accumulates every received chunk into a single growing binary with no size cap. Additionally, when the client omits the grpc-timeout header, the per-chunk read timeout resolves to :infinity, allowing a slow-trickle client to keep the connection alive indefinitely while memory grows. A single connection is sufficient to exhaust server memory and crash the node. This issue affects grpc from 0.3.1 before 1.0.0.
Allocation of Resources Without Limits or Throttling
Stay on top of Security Vulnerabilities
Want an email whenever new vulnerabilities are published for Elixir Grpc Grpc or by Elixir Grpc? Click the Watch button to subscribe.
