Is there a public PoC exploit available for CVE-2026-42788?

Yes, a public proof-of-concept exploit is available for CVE-2026-42788. Prioritise patching immediately. EPSS: 0.0%.

Is there a patch available for CVE-2026-42788?

Yes, a patch is available for CVE-2026-42788. Update the affected software to the latest version immediately.

mtrudel bandit CVE-2026-42788

Q: What is the CVSS score of CVE-2026-42788?

CVE-2026-42788 has a CVSS 4.0 base score of 6.9 (Medium). 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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-26716 MEDIUM

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-05-01 EEF

GHSA-q6v9-r226-v65f

Denial Of Service Red Hat

6.9

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Red Hat

7.5 HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

May 01, 2026 - 23:15 vuln.today

Analysis Generated

May 01, 2026 - 23:15 vuln.today

CVSS changed

May 01, 2026 - 21:22 NVD

6.9 (MEDIUM)

EUVD ID Assigned

May 01, 2026 - 21:01 euvd

EUVD-2026-26716

Analysis Generated

May 01, 2026 - 21:01 vuln.today

Patch released

May 01, 2026 - 21:01 nvd

Patch available

CVE Published

May 01, 2026 - 20:34 nvd

MEDIUM 6.9

DescriptionCVE.org

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.

AnalysisAI

Denial of service in mtrudel bandit via HTTP/2 frame deserialization allows unauthenticated remote attackers to exhaust server memory by sending oversized frames. The vulnerability exists because the HTTP/2 frame parser in 'Elixir.Bandit.HTTP2.Frame':deserialize/2 performs the max frame size check after pattern-matching the entire payload into memory, rather than before, allowing attackers to force buffering of up to 16 MiB frames regardless of negotiated limits. Confirmed actively exploited (CISA KEV status unknown but vendor advisory confirms vulnerability). Patch available in version 1.11.0.

Technical ContextAI

mtrudel bandit is an Erlang/Elixir HTTP server library implementing RFC 9113 HTTP/2. The vulnerability resides in the frame deserialization logic (lib/bandit/http2/frame.ex), where Erlang's binary pattern matching with size constraints (payload::binary-size(length)) requires the entire specified binary sequence to exist in memory before the pattern can match. The issue stems from CWE-770 (Allocation of Resources Without Limits or Throttling): the code structure evaluates the guard clause when length > max_frame_size only after the pattern match succeeds, meaning the Erlang runtime must first allocate and buffer the full frame payload (up to 24-bit max ~16.7 MiB) before the size validation logic executes. RFC 9113 Section 4.2 specifies a default SETTINGS_MAX_FRAME_SIZE of 16 KiB; the vulnerability allows bypassing this negotiated limit through buffering of larger frames on the receive side.

RemediationAI

Vendor-released patch: upgrade to bandit version 1.11.0 or later, which moves the max_frame_size guard clause before the binary pattern match, validating frame length against the negotiated limit before attempting to allocate memory for the payload. The fix (commit 1e8e55966da9129016b73d32f0e1df4630e3b463) restructures the deserialize/2 function to check the 24-bit length field against max_frame_size immediately upon frame header parsing, rejecting oversized frames before buffering. For systems unable to immediately upgrade, apply connection rate limiting and per-connection memory quotas at the reverse proxy or load balancer level (nginx, HAProxy, Envoy) to prevent single clients from establishing excessive concurrent connections. Additionally, configure explicit HTTP/2 frame size limits in upstream load balancers if available; however, note that kernel-level TCP buffering will still occur and cannot be fully eliminated without rejecting connections. Monitor memory usage per connection and implement circuit breakers for connections exceeding baseline consumption. These workarounds add latency and complexity but do not fully eliminate the vulnerability; upgrade is strongly recommended.