elixir-grpc CVE-2026-48599
HIGHSeverity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/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-exploitable by any authenticated user (PR:L), but AC:H reflects the need for a transcoded route whose path binding matches an authorization field; high C/I impact via IDOR, no availability impact.
Primary rating from Vendor (EEF).
CVSS VectorVendor: EEF
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/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
Authorization Bypass Through User-Controlled Key vulnerability in elixir-grpc grpc allows authenticated attackers to access or modify resources belonging to other users by smuggling a conflicting value for any path-bound field via the query string or request body.
In 'Elixir.GRPC.Server.Transcode':map_request/5 (lib/grpc/server/transcode.ex), all three clauses use Map.merge/2 with path bindings as the first argument, giving them the lowest merge precedence. A request such as GET /users/me/profile?user_id=victim (or a POST with {"user_id": "victim"} when body: "*") yields a decoded protobuf struct where the path-bound field carries the attacker-supplied value rather than the router-extracted value. Any handler that uses the path-bound field for authorization, multi-tenancy scoping, or ownership checks is silently bypassed.
This issue affects grpc from 0.8.0 before 1.0.0.
AnalysisAI
Authorization bypass in elixir-grpc (grpc library for Elixir) versions 0.8.0 through 0.x allows authenticated attackers to override path-bound URL parameters via query string or request body values, defeating ownership and multi-tenancy checks. The flaw stems from incorrect Map.merge/2 precedence in GRPC.Server.Transcode.map_request/5, where attacker-controlled query/body values silently overwrite the router-extracted path bindings used by handlers for authorization. No public exploit identified at time of analysis, but upstream patch and detailed regression tests are publicly available.
Technical ContextAI
The vulnerability lives in the gRPC-Gateway-style HTTP transcoding layer of the elixir-grpc library (cpe:2.3:a:elixir-grpc:grpc), which maps REST/HTTP requests onto protobuf service methods. In lib/grpc/server/transcode.ex, three clauses of map_request/5 built the decoded protobuf struct using Map.merge(path_bindings, query) and Map.merge(path_bindings, body) - because Map.merge/2 in Elixir gives the SECOND argument precedence on key conflicts, query-string and body fields would overwrite identically named path bindings. This is a textbook CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR) issue: the trust boundary assumption that 'the path identifies the resource' is broken because the same field name on the wire is allowed to come from an untrusted location.
RemediationAI
Vendor-released patch: upgrade elixir-grpc 'grpc' to 1.0.0 or later, which reverses the Map.merge argument order so path bindings take precedence over query and body (commit 33b6a095dbc91c6dee3c7b90893d7d74952e82e4). Track the advisory at https://github.com/elixir-grpc/grpc/security/advisories/GHSA-mwr4-5g34-j5cq. If immediate upgrade is not possible, compensating controls include disabling HTTP/JSON transcoding for sensitive RPCs and using only native gRPC where the path-binding ambiguity does not arise, stripping or rejecting requests where authorization-relevant fields (e.g., user_id, tenant_id, account_id) appear in both the URL path and the query/body at an upstream proxy or plug, or re-deriving the authorization subject in each handler from the authenticated session/JWT rather than from the decoded protobuf field - trade-offs are reduced REST usability and additional middleware code that must be kept in sync with route definitions.
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
Unauthenticated denial of service in the elixir-grpc library (versions 0.3.1 up to but not including 1.0.0) allows a sin
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 Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today