GHSA-q8gf-9rvj-gmgj
Fix: elixir-grpc/grpc#542GHSA-q8gf-9rvj-gmgj is a CWE-770 vulnerability in grpc. O3 Security confirms whether GHSA-q8gf-9rvj-gmgj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
gRPC Erlang package has unbounded request body accumulation in `read_full_body/3`
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.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for grpc. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update grpc to 1.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-q8gf-9rvj-gmgj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-q8gf-9rvj-gmgj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-q8gf-9rvj-gmgj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-q8gf-9rvj-gmgj in your dependencies?
O3 detects GHSA-q8gf-9rvj-gmgj across Hex dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.