<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sun, 04 Oct 2026 11:20:58 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-375485</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-375485</link>
      <description>EUVD-2026-375485</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-375485</guid>
    </item>
    <item>
      <title>fkie_cve-2026-48854</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-48854</link>
      <description>&lt;p&gt;Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpc allows unauthenticated attackers to exhaust the BEAM&amp;#39;s memory and crash the server by streaming a large or slow-trickle unary request body.&lt;/p&gt;
&lt;p&gt;&amp;#39;Elixir.GRPC.Server.Adapters.Cowboy.Handler&amp;#39;:read_full_body/3 (lib/grpc/server/adapters/cowboy/handler.ex) accumulates every received chunk into a single growing binary with no size cap. Additionally, when the client omits the grpc-timeout header, the per-chunk read timeout resolves to :infinity, allowing a slow-trickle client to keep the connection alive indefinitely while memory grows. A single connection is sufficient to exhaust server memory and crash the node.&lt;/p&gt;
&lt;p&gt;This issue affects grpc: from 0.3.0-alpha.2 before 1.0.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Allocation of Resources Without Limits or Throttling vulnerability in elixir-grpc grpc allows unauthenticated attackers to exhaust the BEAM&amp;#39;s memory and crash the server by streaming a large or slow-trickle unary request body.&lt;/p&gt;
&lt;p&gt;&amp;#39;Elixir.GRPC.Server.Adapters.Cowboy.Handler&amp;#39;:read_full_body/3 (lib/grpc/server/adapters/cowboy/handler.ex) accumulates every received chunk into a single growing binary with no size cap. Additionally, when the client omits the grpc-timeout header, the per-chunk read timeout resolves to :infinity, allowing a slow-trickle client to keep the connection alive indefinitely while memory grows. A single connection is sufficient to exhaust server memory and crash the node.&lt;/p&gt;
&lt;p&gt;This issue affects grpc: from 0.3.0-alpha.2 before 1.0.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-48854</guid>
    </item>
    <item>
      <title>GHSA-q8gf-9rvj-gmgj — gRPC Erlang package has unbounded request body accumulation in `read_full_body/3`</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-q8gf-9rvj-gmgj</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: grpc&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`&amp;#39;Elixir.GRPC.Server.Adapters.Cowboy.Handler&amp;#39;: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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;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 &amp;lt;&amp;gt; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: grpc&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;`&amp;#39;Elixir.GRPC.Server.Adapters.Cowboy.Handler&amp;#39;: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.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;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 &amp;lt;&amp;gt; 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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-q8gf-9rvj-gmgj</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-48854 — Unbounded request body accumulation causes memory exhaustion in elixir-grpc/grpc</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-48854</link>
      <description>msrc_CVE-2026-48854</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-48854</guid>
    </item>
  </channel>
</rss>
