<?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>Wed, 07 Oct 2026 13:46:37 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-322087</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-322087</link>
      <description>EUVD-2026-322087</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-322087</guid>
    </item>
    <item>
      <title>fkie_cve-2026-42788</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-42788</link>
      <description>&lt;p&gt;Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated memory exhaustion via oversized HTTP/2 frames.&lt;/p&gt;
&lt;p&gt;&amp;#39;Elixir.Bandit.HTTP2.Frame&amp;#39;:deserialize/2 in lib/bandit/http2/frame.ex checks the SETTINGS_MAX_FRAME_SIZE limit only after pattern-matching payload::binary-size(length), which requires the entire frame body to be present in memory before either the accept or reject clause can fire. A peer that announces a frame length up to the 24-bit maximum (~16 MiB) causes the server to buffer that entire body before the size guard is evaluated, regardless of the max_frame_size negotiated during the HTTP/2 handshake (default 16 KiB per RFC 9113).&lt;/p&gt;
&lt;p&gt;An unauthenticated attacker holding many concurrent connections can force the server to buffer far more memory than the negotiated frame size limit should permit, leading to memory pressure and potential denial of service.&lt;/p&gt;
&lt;p&gt;This issue affects bandit: from 0.3.6 before 1.11.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated memory exhaustion via oversized HTTP/2 frames.&lt;/p&gt;
&lt;p&gt;&amp;#39;Elixir.Bandit.HTTP2.Frame&amp;#39;:deserialize/2 in lib/bandit/http2/frame.ex checks the SETTINGS_MAX_FRAME_SIZE limit only after pattern-matching payload::binary-size(length), which requires the entire frame body to be present in memory before either the accept or reject clause can fire. A peer that announces a frame length up to the 24-bit maximum (~16 MiB) causes the server to buffer that entire body before the size guard is evaluated, regardless of the max_frame_size negotiated during the HTTP/2 handshake (default 16 KiB per RFC 9113).&lt;/p&gt;
&lt;p&gt;An unauthenticated attacker holding many concurrent connections can force the server to buffer far more memory than the negotiated frame size limit should permit, leading to memory pressure and potential denial of service.&lt;/p&gt;
&lt;p&gt;This issue affects bandit: from 0.3.6 before 1.11.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-42788</guid>
    </item>
    <item>
      <title>GHSA-q6v9-r226-v65f — Bandit HTTP/2 Frame Size Limit Bypass via Late Buffer Check Enables Memory Exhaustion</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-q6v9-r226-v65f</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: bandit&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Bandit&amp;#39;s HTTP/2 parser checks frame size *after* it has already buffered the full body, instead of when it sees the 9-byte header. A peer can announce a 16 MiB frame on a connection that agreed to 16 KiB frames and the server will silently buffer up to 1024× the agreed budget per connection. Across many connections this becomes a memory-pressure DoS. Severity: medium.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In `lib/bandit/http2/frame.ex:23-65`, every clause that could detect an oversized frame requires `payload::binary-size(length)` to match — meaning the body has to be fully in memory before the size guard runs. Until then the parser returns `{:more, msg}` and the connection layer keeps reading. So the cap fires only after the violation is complete.&lt;/p&gt;
&lt;p&gt;The frame type and stream id don&amp;#39;t matter; the parser never gets that far.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;The script is at the end. It:&lt;/p&gt;
&lt;p&gt;1. Opens an h2c connection to a Bandit server it starts itself.
2. Sends a 9-byte frame header announcing `length = 0xFFFFFF` (~16 MiB).
3. Polls for `GOAWAY(FRAME_SIZE_ERROR)`. If silent, drips body bytes in 64 KiB chunks.&lt;/p&gt;
&lt;p&gt;A patched server sends GOAWAY on the header alone. A vulnerable server stays silent and keeps accepting bytes.&lt;/p&gt;
&lt;p&gt;**Suggested fix**&lt;/p&gt;
&lt;p&gt;Add a header-only clause that rejects on the length field alone, e.g. `def deserialize(&amp;lt;&amp;lt;length::24, _::binary&amp;gt;&amp;gt; = msg, max_frame_size) when length &amp;gt; max_frame_size, do: {{:error, frame_size_error(), &amp;#34;...&amp;#34;}, drop_frame_or_close(msg)}`, placed before the body-bearing clauses so…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Hex: bandit&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Bandit&amp;#39;s HTTP/2 parser checks frame size *after* it has already buffered the full body, instead of when it sees the 9-byte header. A peer can announce a 16 MiB frame on a connection that agreed to 16 KiB frames and the server will silently buffer up to 1024× the agreed budget per connection. Across many connections this becomes a memory-pressure DoS. Severity: medium.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In `lib/bandit/http2/frame.ex:23-65`, every clause that could detect an oversized frame requires `payload::binary-size(length)` to match — meaning the body has to be fully in memory before the size guard runs. Until then the parser returns `{:more, msg}` and the connection layer keeps reading. So the cap fires only after the violation is complete.&lt;/p&gt;
&lt;p&gt;The frame type and stream id don&amp;#39;t matter; the parser never gets that far.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;The script is at the end. It:&lt;/p&gt;
&lt;p&gt;1. Opens an h2c connection to a Bandit server it starts itself.
2. Sends a 9-byte frame header announcing `length = 0xFFFFFF` (~16 MiB).
3. Polls for `GOAWAY(FRAME_SIZE_ERROR)`. If silent, drips body bytes in 64 KiB chunks.&lt;/p&gt;
&lt;p&gt;A patched server sends GOAWAY on the header alone. A vulnerable server stays silent and keeps accepting bytes.&lt;/p&gt;
&lt;p&gt;**Suggested fix**&lt;/p&gt;
&lt;p&gt;Add a header-only clause that rejects on the length field alone, e.g. `def deserialize(&amp;lt;&amp;lt;length::24, _::binary&amp;gt;&amp;gt; = msg, max_frame_size) when length &amp;gt; max_frame_size, do: {{:error, frame_size_error(), &amp;#34;...&amp;#34;}, drop_frame_or_close(msg)}`, placed before the body-bearing clauses so…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-q6v9-r226-v65f</guid>
    </item>
  </channel>
</rss>
