Am I affected?
Description
'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.
Weaknesses & attack patterns
Weakness
CWE-770
·
Allocation of Resources Without Limits or Throttling
in catalog →
MITRE ↗
Attack patterns
CAPEC-130
·
Excessive Allocation
MITRE ↗
Affected — Hex / bandit Hex.pm ↗ Repository ↗
modules · source files · routines
Affected — GitHub / mtrudel/bandit Repository ↗
modules · source files · routines
References
GHSA-q6v9-r226-v65f ↗
vendor-advisory
EEF-CVE-2026-42788 ↗
related
Credits
CVSS breakdown
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