CVE-2026-48854 — grpc
Fix: elixir-grpc/grpc@49e18c3CVE-2026-48854 is a CWE-770 vulnerability in grpc. A fix is available for grpc — see the affected versions and patch details below.
Unbounded request body accumulation causes memory exhaustion in elixir-grpc/grpc
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-48854.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
grpcReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Hex packages — download data is not available via public APIs for these ecosystems.
Description
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
- Start any
grpcserver exposing a unary RPC (no special configuration required). - Open an HTTP/2 connection and send a POST to any unary RPC path with
Content-Type: application/grpc+proto— omit thegrpc-timeoutheader. - Stream a large body (e.g. 1 GiB) in chunks without sending the final
END_STREAMflag immediately. - 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | grpc | ≥ 0.3.1&&< 1.0.0 | 1.0.0mix deps.update grpc |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for grpc, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update grpc to 1.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-48854 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Frequently Asked Questions
Is CVE-2026-48854 in your dependencies?
Find it across Hex, including transitive dependencies.