CVE-2026-48854: Unauthenticated Denial of Service via Resource Exhaustion in elixir-grpc Server

The Elixir grpc package serves as a critical component for high-performance remote procedure call communication within the Elixir and Erlang BEAM VM ecosystem. It acts as an abstraction layer over Cowboy, an HTTP server written in Erlang. The server-side adapter component is responsible for receiving inbound HTTP/2 connections, parsing gRPC request envelopes, and dispatching execution flows to the appropriate application gRPC services.\n\nA weakness in this component allows remote attackers to exhaust the available memory of the host Erlang VM. This vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling) and CWE-400 (Uncontrolled Resource Consumption). The attack surface resides entirely in the Cowboy handler adapter, which parses incoming request bodies for unary RPC operations.\n\nThe underlying threat classification is mapped to MITRE ATT&CK T1499 (Endpoint Denial of Service). Because the Erlang BEAM virtual machine operates on a single OS process sharing a global memory allocator, exhausting memory in one connection handler process can cause a fatal VM panic. This crashes the entire application node, terminating all other active connections and background processes hosted on the node.

To analyze the root cause, we must look at the interactions between Cowboy and the gRPC handler process during a unary request lifecycle. For unary gRPC endpoints, the server must parse the complete payload prior to executing the service method. The vulnerable handler initiates this body extraction by invoking :cowboy_req.read_body/2 inside a recursive utility function.\n\nThe fundamental flaw is the lack of constraint validation on the accumulated binary size. As long as the network socket delivers more segments, the Cowboy handler appends incoming bytes to the existing buffer using binary concatenation. In the BEAM VM, binary payloads larger than 64 bytes are categorized as reference-counted (refc) binaries and allocated on a shared global heap. Repeatedly appending data within a tight recursive loop causes significant allocator overhead and memory fragmentation.\n\nThis behavior is further compounded by the automatic issuance of HTTP/2 flow control frames. As the Cowboy adapter drains the socket and transfers buffers to the handler, the underlying TCP/IP stack and HTTP/2 protocol engine issue WINDOW_UPDATE frames back to the client. This notifies the sender that the window capacity has cleared, enabling the client to stream arbitrary quantities of data uninterrupted by transport-level congestion controls.\n\nFinally, the adapter implements a custom calculation to estimate remaining execution time for the read timeout constraint. If the incoming gRPC request does not include a grpc-timeout header, this calculation defaults the read timeout explicitly to :infinity. This overrides Cowboy's built-in 15-second default read timeout safety limit, allowing slow-sending clients to maintain open sockets indefinitely while slowly inflating memory consumption.

The vulnerable routine is located in lib/grpc/server/adapters/cowboy/handler.ex inside the private function read_full_body/3. This function recursively receives body segments from Cowboy without tracking or limiting the buffer's growth.\n\nelixir\n# Vulnerable Implementation\ndefp read_full_body(req, body, timer) do\n result = :cowboy_req.read_body(req, timeout_left_opt(timer))\n\n case result do\n {:ok, data, req} -> {:ok, body <> data, req}\n {:more, data, req} -> read_full_body(req, body <> data, timer)\n end\nend\n\n\nThe patched implementation establishes a default maximum body size threshold (@default_max_body_size) of 4 MB to match industry-standard gRPC implementations. The revised recursive path tracks the accumulated data size and explicitly checks the byte count before performing subsequent socket read actions.\n\nelixir\n# Patched Implementation\ndefp read_full_body(req, body, timer, max_bytes) do\n result = :cowboy_req.read_body(req, timeout_left_opt(timer))\n\n case result do\n {:ok, data, req} ->\n total = body <> data\n if byte_size(total) > max_bytes do\n throw({:body_too_large, byte_size(total)})\n else\n {:ok, total, req}\n end\n\n {:more, data, req} ->\n total = body <> data\n if byte_size(total) > max_bytes do\n throw({:body_too_large, byte_size(total)})\n else\n read_full_body(req, total, timer, max_bytes)\n end\n end\nend\n\n\nThe patch also addresses the timeout fallback loophole. The modified timeout_left_opt/2 function no longer overrides Cowboy's configuration with :infinity when a timer is absent. By leaving the options map unchanged, Cowboy falls back to its default 15-second chunk read timeout, ensuring that connections cannot be kept open indefinitely by slow-trickling clients. This combination of size checks and active timeout management provides a complete mitigation against both bulk flooding and slow-rate DoS strategies.

An attacker can exploit this vulnerability through two distinct attack methodologies. The first methodology is a fast-flood memory exhaustion attack targeting the lack of message size bounds. The attacker initiates a standard HTTP/2 cleartext (h2c) connection or a TLS-encrypted gRPC connection and sends a Unary RPC call request envelope.\n\nOnce the connection is established, the attacker sends a continuous stream of arbitrary data bytes instead of a valid, terminated protocol buffer message. Because the Cowboy adapter continuously reads incoming data and performs binary concatenation on the global heap, the target server's memory usage spikes. A single client connection transmitting at high speed can consume gigabytes of memory within seconds, triggering the operating system's Out-of-Memory (OOM) killer or a BEAM runtime panic.\n\nThe second methodology is a slow-rate Denial of Service (similar to Slowloris). The attacker initiates a Unary RPC call but deliberately omits the grpc-timeout header from the request metadata. The attacker then slowly transmits payload fragments, such as sending 1 byte every 10 seconds.\n\nmermaid\nsequenceDiagram\n autonumber\n Actor Attacker as Remote Attacker\n Participant Server as gRPC Cowboy Server\n Participant BEAM as BEAM VM Allocator\n Attacker->>Server: HTTP/2 POST /Service/Method (No grpc-timeout)\n Note over Server: timer is nil -> timeout set to :infinity\n loop Slow Trickle / Infinite Stream\n Attacker->>Server: Send Data Fragment (Slow rate or large size)\n Server->>BEAM: Allocate Refc Binary (body <> data)\n Note over BEAM: Memory expands without limit\n end\n Note over BEAM: Memory exhausted (OOM)\n BEAM-->>Server: Crash Process / VM Exit\n\n\nSince the server lacks a functional timeout for this socket read loop, the connection is held open indefinitely. An attacker can run dozens of concurrent sessions with low bandwidth footprint to lock down system file descriptors and accumulate heaps of allocated binaries, exhausting system resources with minimal network overhead.

The impact of successful exploitation is a complete denial of service. Since the Erlang BEAM VM is designed to run as a single OS process hosting many thousands of lightweight concurrent processes, a critical memory allocation failure affects the entire VM. If the global memory allocators (eheap_alloc or binary_alloc) fail to obtain a contiguous chunk of memory from the operating system, the BEAM emulator terminates immediately.\n\nThis crash is unrecoverable and terminates all applications running on the same node, including unrelated microservices, database connections, and background workers. For containerized deployments, such as those running on Kubernetes, an Out-Of-Memory (OOM) crash triggers an immediate pod termination. While container orchestrators can automatically restart the container, repeated exploitation will lead to a CrashLoopBackOff state, causing prolonged system downtime.\n\nThe CVSS v4.0 score of 8.7 reflects the high availability impact (VA:H). The vulnerability requires no authentication (PR:N) and low complexity (AC:L), meaning it can be launched easily by any remote network agent with visibility to the gRPC service port.

The primary remediation strategy is upgrading the elixir-grpc/grpc dependency to version 1.0.0 or higher. In this release, the project restructured its architecture, splitting the core client library and the server component into two distinct packages: :grpc and :grpc_server. Security-critical enhancements, including the binary size checks and timeout fixes, are natively integrated into the :grpc_server component.\n\nOrganizations must update their dependency configuration in the mix.exs file to import the new packages and enforce the correct version constraints. Ensure that any legacy grpc dependencies before version 1.0.0 are removed from the server-side codebases.\n\nFor environments where an immediate dependency upgrade is not feasible, temporary defensive measures should be deployed. Administrators can restrict maximum body sizes at the ingress controller, reverse proxy (such as Nginx or Envoy), or Web Application Firewall (WAF) layer. Enforcing an HTTP/2 request body limit at the load balancer will block oversize packets before they reach the backend Elixir Cowboy server, effectively mitigating the bulk memory exhaustion vector.