CVE-2026-48853: Remote Code Execution and Denial of Service in elixir-grpc via Erlpack Deserialization

The grpc package for Elixir (specifically elixir-grpc) provides support for the gRPC protocol over HTTP/2 inside the Erlang VM (BEAM). A core component of this implementation is its codec architecture, which enables decoding incoming payloads of different formats depending on the request headers. When the Erlpack codec is configured, the server decodes incoming payloads using Erlang External Term Format (ETF).

By sending a crafted request with the Content-Type: application/grpc+erlpack header, an unauthenticated remote attacker can trigger deserialization of untrusted ETF payloads. This processing exposes the server to both Denial of Service (DoS) and Remote Code Execution (RCE) vectors. The flaw stems from the library invoking Erlang's deserialization primitive without adequate safeguards, failing to restrict resource allocation or prevent the materialization of executable code objects.

The vulnerability is tracked under CVE-2026-48853 and GHSA-grp7-v8xh-rj7h. It represents a critical threat because the affected endpoint requires no authentication and is exposed directly to the network. The CVSS 4.0 base score is evaluated at 9.2, reflecting high confidentiality, integrity, and availability impacts on the affected host. System administrators and developers must take immediate action to either upgrade their dependencies or disable the affected codec.

The root cause of this vulnerability lies in the implementation of the decode/2 function in lib/grpc/codec/erlpack.ex. The grpc framework permits multiple content-types for payload serialization, with application/grpc+erlpack mapping to the GRPC.Codec.Erlpack module. Prior to the fix, the decoder parsed raw incoming binary data directly by invoking :erlang.binary_to_term/1 without the :safe option and without verifying the structured type of the decoded payload.

Erlang's :erlang.binary_to_term/1 reconstructs Erlang External Term Format (ETF) streams back into in-memory BEAM terms. This behavior presents a significant security risk when exposed to untrusted input. Under ETF specification, terms can represent primitive types, composite structures, or complex control structures like compiled anonymous functions (funs) and global identifier references. Parsing unvalidated ETF payloads triggers two distinct security failures, namely atom table exhaustion and dynamic executable term injection.

First, the BEAM virtual machine utilizes a global, shared table to store atoms, which are immutable symbolic constants. Crucially, the virtual machine does not garbage-collect atoms. The atom table is bounded by a hard-coded limit of 1,048,576 entries by default. An attacker sending serialized ETF structures containing unique, randomized atom identifiers forces the parser to allocate new atoms inside the table. This rapidly consumes all available slots, throwing a terminal SystemLimitError and instantly crashing the entire BEAM node.

Second, ETF supports the serialization of compiled anonymous functions (funs). When the VM deserializes an ETF payload containing a compiled fun, it instantiates the function object directly into memory. If the decoded term flows into a downstream execution context—such as passing the term to list-processing utilities, logging functions, mapping routines, or database drivers—the VM executes the arbitrary code embedded in the fun. Because elixir-grpc did not filter out executable types post-deserialization, this path provides a reliable mechanism for remote code execution.

The original, vulnerable implementation of the codec in lib/grpc/codec/erlpack.ex was minimal and assumed all incoming data was well-formed and safe. It executed the following block of code:

defmodule GRPC.Codec.Erlpack do
  @behaviour GRPC.Codec
 
  def name() do
    "erlpack"
  end
 
  def decode(binary, _module) do
    :erlang.binary_to_term(binary)
  end
end

This simple implementation passed the raw payload binary directly to the unsafe :erlang.binary_to_term/1 function. The lack of options and post-processing left the VM fully exposed to arbitrary term instantiation.

To resolve this vulnerability, the developers modified the decoding routine to use the :safe option and introduced a strict, recursive validation function called ensure_safe_term!/1. The updated implementation is shown below:

defmodule GRPC.Codec.Erlpack do
  @behaviour GRPC.Codec
 
  def name() do
    "erlpack"
  end
 
  def decode(binary, _module) do
    # The :safe option prevents the parser from creating new atoms.
    term = :erlang.binary_to_term(binary, [:safe])
    # Recursively check the term for forbidden data types.
    ensure_safe_term!(term)
    term
  end
 
  # Raise an error if the term contains forbidden execution elements
  defp ensure_safe_term!(term)
       when is_function(term) or is_pid(term) or is_port(term) or is_reference(term) do
    raise ArgumentError,
          "refusing to decode unsafe erlpack payload containing a #{term_type(term)}"
  end
 
  defp ensure_safe_term!(term) when is_list(term) do
    Enum.each(term, &ensure_safe_term!/1)
  end
 
  defp ensure_safe_term!(term) when is_tuple(term) do
    term |> Tuple.to_list() |> Enum.each(&ensure_safe_term!/1)
  end
 
  defp ensure_safe_term!(term) when is_map(term) do
    # Map.to_list/1 is used to iterate over plain maps and structs safely
    Enum.each(Map.to_list(term), fn {key, value} ->
      ensure_safe_term!(key)
      ensure_safe_term!(value)
    end)
  end
 
  defp ensure_safe_term!(_term), do: :ok
 
  defp term_type(term) when is_function(term), do: "function"
  defp term_type(term) when is_pid(term), do: "pid"
  defp term_type(term) when is_port(term), do: "port"
  defp term_type(term) when is_reference(term), do: "reference"
end

The fix is complete because it addresses both vulnerability vectors. The :safe flag prevents the generation of novel atoms, neutralizing the atom-table exhaustion vector. Concurrently, the recursive ensure_safe_term!/1 traversal blocks the materialization of function, pid, port, and reference types. These are types that do not belong in a legitimate gRPC payload and are often abused to bypass sandbox constraints or achieve code execution across different Erlang releases.

To exploit this vulnerability, an attacker targets the gRPC listener port (typically 50051) over HTTP/2. The exploit relies on initiating a standard gRPC call but modifying the metadata headers and the body payload. The headers must specify Content-Type: application/grpc+erlpack to route the incoming binary payload to the vulnerable codec.

The attack flow is visualized in the following diagram:

For a Denial of Service attack, the payload consists of an ETF array populated with unique small UTF-8 atoms. An attacker can generate these systematically. When the BEAM parser encounters each new atom definition, it registers it globally. Sending a stream of distinct atoms across multiple concurrent HTTP/2 streams quickly exhausts the remaining allocation slots in the atom table, forcing the VM to execute an unrecoverable shut down.

For Remote Code Execution, the attacker serializes an anonymous function. For example, an attacker can compile a fun executing an OS system command using System.cmd/2. The compiled function bytecode is serialized into ETF using native Erlang functions. When the server processes the payload, the fun is reconstructed in memory. If any downstream application logic maps over the deserialized structure or invokes a callback on the payload elements, the embedded function executes within the context of the running application, granting the attacker shell access.

The impact of CVE-2026-48853 is critical. Successful exploitation yields remote code execution or complete service denial. Because the vulnerable code path executes immediately upon receiving and parsing the HTTP/2 gRPC frame headers and body, the attacker does not need to bypass authentication checks or possess valid credentials. Any network-exposed gRPC endpoint supporting Erlpack serialization is vulnerable.

If the attacker pursues Denial of Service, the consequence is a persistent and total crash of the hosting BEAM node. Recovering from this state requires an external orchestration service (such as Kubernetes or systemd) to restart the container or daemon. This creates a highly reliable attack vector for disrupting critical communications, particularly in distributed microservice architectures that rely heavily on gRPC for internal coordination.

If the attacker pursues Remote Code Execution, the compromise is absolute. The executed commands run with the privileges of the OS user running the BEAM VM. The attacker can read configuration environment variables, extract secrets, access localized databases, and pivot deeper into the internal network. In containerized environments, this execution can serve as a stepping stone to cluster-wide compromise if the container possesses elevated capabilities or holds service account tokens.

The primary and most effective remediation strategy is to upgrade elixir-grpc to version 1.0.0 or higher. This version implements the safe deserialization workflow and eliminates the vulnerability entirely. Users should update their project dependencies and redeploy the affected applications.

If upgrading is not immediately feasible, teams can apply defensive configurations to mitigate the risk. The first temporary measure is to restrict the supported codecs on the gRPC servers. By default, applications should only declare GRPC.Codec.Proto in their server module configuration. Removing GRPC.Codec.Erlpack from the codecs key prevents the server from routing requests to the vulnerable decoding logic, rejecting application/grpc+erlpack requests at the frame-routing level.

Additionally, network-level mitigations can be implemented at the ingress controller, reverse proxy, or Web Application Firewall (WAF) layer. Since the exploit depends on the Content-Type header, administrators can configure NGINX, Envoy, or HAProxy to inspect the Content-Type header of incoming gRPC traffic. Any HTTP/2 request with a Content-Type matching application/grpc+erlpack should be blocked and logged as an intrusion attempt before reaching the backend BEAM nodes.