gRPC Erlang package's path bindings are overridable by query string and request bodyGHSA-mwr4-5g34-j5cq
Fix: elixir-grpc/grpc#541GHSA-mwr4-5g34-j5cq is a CWE-639 vulnerability in grpc. A fix is available for grpc — see the affected versions and patch details below.
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.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-mwr4-5g34-j5cq.
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
In the HTTP-to-gRPC transcoding layer of the grpc Hex package, query-string and request-body parameters can silently overwrite path-bound fields when building the decoded protobuf request struct. An authenticated attacker who can reach a transcoded endpoint can substitute any path-bound identifier (e.g. user_id from /users/{user_id}/profile) with an arbitrary value, bypassing authorization, multi-tenancy, and ownership checks that rely on the path-derived field.
Details
All three clauses of GRPC.Server.Transcode.map_request/5 (grpc_server/lib/grpc/server/transcode.ex) use Map.merge/2 with path bindings as the first argument, giving them the lowest merge precedence. Path bindings are extracted by the router from the matched URL template and should be the authoritative resource identifiers, but query-string and body parameters overwrite them. The decoded protobuf struct handed to the handler carries the attacker's value instead of the router's.
PoC
- Deploy a transcoded gRPC service with a route like
GET /users/{user_id}/profilewhere the handler authorizes access based onrequest.user_id. - Send:
GET /users/me/profile?user_id=victim - The decoded request struct has
user_id = "victim"— the authorization check passes for the victim's resource, not the caller's. - Alternatively, for a
POSTwithbody: "*": send{"user_id": "victim"}in the JSON body.
Impact
Affects applications using grpc ≥ 0.8.0 with HTTP transcoding enabled that rely on path-bound fields for authorization or tenant isolation. Fixed in 1.0.0. An authenticated attacker can read or modify any other user's resources exposed via transcoded endpoints.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💧Hex | grpc | ≥ 0.8.0&&< 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 GHSA-mwr4-5g34-j5cq 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.
Frequently Asked Questions
Is GHSA-mwr4-5g34-j5cq in your dependencies?
Find it across Hex, including transitive dependencies.