Because the deserialization process is unsafe, it permits the instantiation of arbitrary terms, including function objects (fun terms) and large numbers of atoms. An attacker can exploit this in two ways: by saturating the BEAM global atom table (which is capped at ~1 million entries) to crash the entire node, or by injecting serialized function terms that execute arbitrary code when subsequently invoked by the host application. This vulnerability is specific to environments where developers have explicitly registered GRPC.Codec.Erlpack in their gRPC server configuration.

Attack Chain

1. Attacker identifies a target gRPC server that has explicitly configured GRPC.Codec.Erlpack as a codec.
2. Attacker establishes a standard HTTP/2 connection to the gRPC service endpoint.
3. Attacker constructs a malicious gRPC payload serialized via :erlang.term_to_binary containing a fun term for RCE or repeated atom definitions for DoS.
4. Attacker sends an HTTP POST request to the gRPC endpoint with the header Content-Type: application/grpc+erlpack.
5. The server's GRPC.Codec.Erlpack.decode/2 function parses the request body and materializes the unsafe terms into the server process memory.
6. For DoS, the accumulated atoms exhaust the BEAM virtual machine's global atom table, resulting in a node-wide crash.
7. For RCE, the malicious fun term is passed to a downstream Elixir call site (such as Enum.map or Task.async).
8. The host application executes the attacker-controlled code within the context of the server process.

Impact

Successful exploitation allows unauthenticated attackers to fully compromise the host server by executing arbitrary code with the privileges of the BEAM virtual machine process. Alternatively, attackers can force a complete denial of service by crashing the node through atom table exhaustion. This vulnerability affects any gRPC-based Elixir application that enables the Erlpack codec.

Recommendation

Prioritize the immediate update of the grpc Elixir package to version 1.0.0 or later, which addresses this deserialization flaw. For environments that cannot immediately patch, remove GRPC.Codec.Erlpack from the list of registered codecs in your gRPC server configuration. Detection engineers should inspect server logs for any incoming requests utilizing the application/grpc+erlpack content type and verify if such usage is expected in the production environment.