VYPR
Medium severityNVD Advisory· Published May 1, 2026· Updated May 5, 2026

CVE-2026-42788

CVE-2026-42788

Description

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated memory exhaustion via oversized HTTP/2 frames.

'Elixir.Bandit.HTTP2.Frame':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).

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.

This issue affects bandit: from 0.3.6 before 1.11.0.

Affected packages

Versions sourced from the GitHub Security Advisory.

PackageAffected versionsPatched versions
banditHex
>= 0.3.5, < 1.11.01.11.0

Affected products

1

Patches

1
1e8e55966da9

Merge commit from fork

https://github.com/mtrudel/banditMat TrudelMay 1, 2026via ghsa
2 files changed · +23 15
  • lib/bandit/http2/frame.ex+14 15 modified
    @@ -25,6 +25,20 @@ defmodule Bandit.HTTP2.Frame do
               | {{:more, iodata()}, <<>>}
               | {{:error, Bandit.HTTP2.Errors.error_code(), binary()}, iodata()}
               | nil
    +  # This is a little more aggressive than necessary. RFC9113§4.2 says we only need
    +  # to treat frame size violations as connection level errors if the frame in
    +  # question would affect the connection as a whole, so we could be more surgical
    +  # here and send stream level errors in some cases. However, we are well within
    +  # our rights to consider such errors as connection errors
    +  def deserialize(
    +        <<length::24, _type::8, _flags::8, _reserved::1, _stream_id::31, rest::binary>>,
    +        max_frame_size
    +      )
    +      when length > max_frame_size do
    +    {{:error, Bandit.HTTP2.Errors.frame_size_error(), "Payload size too large (RFC9113§4.2)"},
    +     rest}
    +  end
    +
       def deserialize(
             <<length::24, type::8, flags::8, _reserved::1, stream_id::31,
               payload::binary-size(length), rest::binary>>,
    @@ -48,21 +62,6 @@ defmodule Bandit.HTTP2.Frame do
         |> then(&{&1, rest})
       end
     
    -  # This is a little more aggressive than necessary. RFC9113§4.2 says we only need
    -  # to treat frame size violations as connection level errors if the frame in
    -  # question would affect the connection as a whole, so we could be more surgical
    -  # here and send stream level errors in some cases. However, we are well within
    -  # our rights to consider such errors as connection errors
    -  def deserialize(
    -        <<length::24, _type::8, _flags::8, _reserved::1, _stream_id::31,
    -          _payload::binary-size(length), rest::binary>>,
    -        max_frame_size
    -      )
    -      when length > max_frame_size do
    -    {{:error, Bandit.HTTP2.Errors.frame_size_error(), "Payload size too large (RFC9113§4.2)"},
    -     rest}
    -  end
    -
       # nil is used to indicate for Stream.unfold/2 that the frame deserialization is finished
       def deserialize(<<>>, _max_frame_size) do
         nil
    
  • test/bandit/http2/frame_deserialization_test.exs+9 0 modified
    @@ -17,6 +17,15 @@ defmodule HTTP2FrameDeserializationTest do
         end
       end
     
    +  describe "oversize frames" do
    +    test "drops oversize frames early" do
    +      frame = <<16_385::24, 0, 0, 0, 0, 0, 1>>
    +
    +      assert Frame.deserialize(frame, 16_384) ==
    +               {{:error, 6, "Payload size too large (RFC9113§4.2)"}, <<>>}
    +    end
    +  end
    +
       describe "extra data" do
         test "returns extra data" do
           frame = <<0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 2, 3>>
    

Vulnerability mechanics

Generated by null/stub on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

6

News mentions

0

No linked articles in our index yet.