Answer in brief
CVE-2026-48854 records a High severity vulnerability in gRPC Erlang package has unbounded request body accumulation in `read_full_body/3`. 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.3.1,<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 `'Elixir.GRPC.Server.Adapters.Cowboy.Handler':read_full_body/3` accumulates every received chunk into a single growing binary with no size cap. When the client omits the `grpc-timeout` header, the read timeout resolves to `:infinity`, allowing a slow-trickle attacker to hold the connection open indefinitely while memory grows. A single unauthenticated connection is sufficient to exhaust BEAM memory and crash the node. ### Details The read loop in `lib/grpc/server/adapters/cowboy/handler.ex` calls `:cowboy_req.read_body/2` in a recursive loop, concatenating each chunk: `body <> data`. There is no running-total check and no configurable maximum body size. As the loop drains the receive buffer, cowboy issues fresh HTTP/2 `WINDOW_UPDATE` frames, so the client can keep pushing data indefinitely. The `grpc-timeout` header is attacker-supplied and optional. When absent, `timeout_left_opt(nil)` returns `:infinity`, so the per-chunk read also has no deadline. The two missing controls compound: a fast client can blast multi-gigabyte payloads directly into memory; a slow client can trickle data forever. ### PoC 1. Start any `grpc` server exposing a unary RPC (no special configuration required). 2. Open an HTTP/2 connection and send a POST to any unary RPC path with `Content-Type: application/grpc+proto` — omit the `grpc-timeout` header. 3. Stream a large body (e.g. 1 GiB) in chunks without sending the final `END_STREAM` flag immediately. 4. Observe BEAM memory growing proportionally to uploaded data with no server-side cap. ### Impact Affects `grpc` ≥ 0.3.1. No authentication, no special configuration, and no specific RPC method required, the unbounded read is on the default unary ingress path. ### References * Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560 * Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00
Quoted source text, attributed separately from HOL analysis.