Answer in brief
CVE-2026-48853 records a Critical severity vulnerability in gRPC Erlang package vulnerable to Remote Code Execution with attacker-controlled gRPC payloads. The current sources do not mark it as known exploited. The current feed maps grpc (erlang). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps grpc (erlang). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| grpcerlang | >=0.4.0,<1.0.0 | 1.0.0 |
Published upstream
Aug 25, 2026
Evidence: source:ghsa:source_dates:source-dates:recordSource modified
Aug 25, 2026
Evidence: source:ghsa:source_dates:source-dates:recordFirst seen by HOL
Aug 25, 2026
### Summary `GRPC.Codec.Erlpack.decode/2` calls `:erlang.binary_to_term/1` directly on the raw gRPC message body without the `:safe` option. Any unauthenticated peer that can reach a gRPC endpoint with `Content-Type: application/grpc+erlpack` can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process. ### Details **Root cause** — `lib/grpc/codec/erlpack.ex` implements `decode/2` as a bare `:erlang.binary_to_term(binary)` call with no `:safe` flag, no size limit, and no type validation. This has two independent exploitation paths: **1. DoS via atom exhaustion** — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node. **2. RCE via fun materialization** — Without `:safe`, `binary_to_term/1` reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. `Enum.map`, `Task.async`, direct invocation), attacker-controlled code executes inside the server process. **Configuration requirement:** `GRPC.Codec.Erlpack` is not registered by default and must be explicitly added to the server's `codecs` option. ### PoC 1. Start a gRPC server with `codecs: [GRPC.Codec.Erlpack]`. 2. Open an HTTP/2 connection to the server. 3. Send a gRPC-framed POST to any RPC path with `Content-Type: application/grpc+erlpack` and a body of `:erlang.term_to_binary(fn -> <malicious_code> end)`. 4. The server's `decode/2` materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code. 5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes. ### Impact Affects `grpc` ≥ 0.4.0. Any server that explicitly registers `GRPC.Codec.Erlpack` is vulnerable to unauthenticated node-level DoS and potentially RCE. ### References * Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9 * Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992
Quoted source text, attributed separately from HOL analysis.