elixir-grpc CVE-2026-48854
HIGHSeverity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable gRPC port (AV:N), single straightforward request (AC:L), no auth or interaction (PR:N/UI:N), and only availability is impacted (A:H, C:N, I:N).
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
2DescriptionCVE.org
Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpc allows unauthenticated attackers to exhaust the BEAM's memory and crash the server by streaming a large or slow-trickle unary request body.
'Elixir.GRPC.Server.Adapters.Cowboy.Handler':read_full_body/3 (lib/grpc/server/adapters/cowboy/handler.ex) accumulates every received chunk into a single growing binary with no size cap. Additionally, when the client omits the grpc-timeout header, the per-chunk read timeout resolves to :infinity, allowing a slow-trickle client to keep the connection alive indefinitely while memory grows. A single connection is sufficient to exhaust server memory and crash the node.
This issue affects grpc from 0.3.1 before 1.0.0.
AnalysisAI
Unauthenticated denial of service in the elixir-grpc library (versions 0.3.1 up to but not including 1.0.0) allows a single remote attacker to crash an Erlang/BEAM node by streaming an oversized or slow-trickle unary gRPC request body. The Cowboy handler's read_full_body/3 accumulates every chunk into one unbounded binary, and when no grpc-timeout header is sent the per-chunk read timeout collapses to :infinity, so memory grows without bound until the VM dies. No public exploit identified at time of analysis, but the fix is upstream in commit 49e18c3 and the issue is trivial to trigger.
Technical ContextAI
The elixir-grpc package implements a gRPC server for the Elixir/Erlang ecosystem using Cowboy as the HTTP/2 transport. The vulnerable code path is GRPC.Server.Adapters.Cowboy.Handler.read_full_body/3 in lib/grpc/server/adapters/cowboy/handler.ex, which recursively concatenates inbound HTTP/2 DATA frames into a single Erlang binary with no size ceiling. A second defect in the same module overrides Cowboy's default 15-second per-chunk read timeout with :infinity whenever the client omits the grpc-timeout header, defeating the only natural throttle on a slow sender. This is a textbook CWE-770 (Allocation of Resources Without Limits or Throttling): an attacker controls both the rate and total size of input, and the server allocates unbounded memory in response. Because BEAM nodes typically host many co-located processes, OOM of the VM is a process-wide outage rather than a single-request failure.
RemediationAI
Upstream fix available (commit 49e18c3ec6bb9afe2f712caad3dbab5c56a68a00); upgrade elixir-grpc/grpc to 1.0.0 or later, which introduces a default 4 MB max_body_size matching gRPC-Go and stops overriding Cowboy's 15-second per-chunk read timeout with :infinity. Operators can override the cap via the new :max_body_size server option (bytes) if their workload legitimately requires larger unary payloads. If immediate upgrade is not possible, compensating controls include placing a reverse proxy (nginx, Envoy, HAProxy) in front of the gRPC server with a client_max_body_size / max_request_bytes limit and an aggressive client_body_timeout - trade-off is that proxies that don't natively understand HTTP/2 trailers may break some gRPC features; additionally, restrict the gRPC port to trusted client networks and add OS-level memory limits (systemd MemoryMax, cgroups) so an OOM kills only the BEAM node rather than starving the host. References: https://github.com/elixir-grpc/grpc/security/advisories/GHSA-q8gf-9rvj-gmgj and https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
Google gRPC before 2017-03-29 has an out-of-bounds write caused by a heap-based use-after-free related to the grpc_call_
It's possible for a gRPC client communicating with a HTTP/2 proxy to poison the HPACK table between the proxy and the ba
Google gRPC before 2017-02-22 has an out-of-bounds write caused by a heap-based buffer overflow related to the parse_uni
Google gRPC before 2017-02-22 has an out-of-bounds write related to the gpr_free function in core/lib/support/alloc.c. R
Google gRPC before 2017-04-05 has an out-of-bounds write caused by a heap-based buffer overflow related to core/lib/iomg
The package grpc before 1.24.4; the package @grpc/grpc-js before 1.1.8 are vulnerable to Prototype Pollution via loadPac
Unsafe Erlang term deserialization in the elixir-grpc library (versions 0.4.0 through 1.0.0) allows unauthenticated remo
Denial of service in the elixir-grpc library (versions 0.4.0 through 0.x) allows unauthenticated remote attackers to cra
Authorization bypass in elixir-grpc (grpc library for Elixir) versions 0.8.0 through 0.x allows authenticated attackers
Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Rated
gRPC contains a vulnerability that allows hpack table accounting errors could lead to unwanted disconnects between clien
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today