Which versions of Bandit are affected by EUVD-2026-26711?

Bandit WebSocket server versions 0.5.9 through 1.10.x are vulnerable to remote denial-of-service attacks via compression bomb payloads when permessage-deflate compression is explicitly enabled.. A patch is available.

Is there a public PoC exploit available for EUVD-2026-26711?

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

How to fix or mitigate EUVD-2026-26711?

Within 24 hours: inventory all Bandit deployments and identify whether permessage-deflate compression is enabled in configuration (check for compress: true in WebSocket upgrade options). Within 7 days: upgrade Bandit to version 1.11.0 or later for all affected instances; test in staging environment first to validate compatibility. Within 30 days: conduct post-patch validation across all production systems and document compression settings in your asset inventory to prevent future misconfigurations.

Bandit EUVD-2026-26711

Q: What is the CVSS score of EUVD-2026-26711?

EUVD-2026-26711 has a CVSS 4.0 base score of 8.2 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/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%.

| CVE-2026-39804 HIGH

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

2026-05-01 EEF

GHSA-frh3-6pv6-rc8j

Denial Of Service Red Hat

8.2

CVSS 4.0 · NVD

Severity by source

NVD PRIMARY

8.2 HIGH

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/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:P/PR:N/UI:N/VC:N/VI:N/VA:H/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:16 vuln.today

Analysis Generated

May 01, 2026 - 23:16 vuln.today

CVSS changed

May 01, 2026 - 21:22 NVD

8.2 (HIGH)

EUVD ID Assigned

May 01, 2026 - 21:01 euvd

EUVD-2026-26711

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

HIGH 8.2

DescriptionCVE.org

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows unauthenticated remote denial of service via memory exhaustion when WebSocket permessage-deflate compression is enabled.

'Elixir.Bandit.WebSocket.PerMessageDeflate':inflate/2 in lib/bandit/websocket/permessage_deflate.ex calls :zlib.inflate/2 with no output-size cap, then materializes the entire decompressed payload as a single binary via IO.iodata_to_binary/1. The websocket_options.max_frame_size option only bounds the on-the-wire (compressed) frame size, not the decompressed output. A high-ratio compressed frame (e.g. uniform data at ~1024:1 ratio) can stay well under any wire-size limit while forcing GiB-scale heap allocations in the connection process before any application code runs.

An unauthenticated attacker who can open a WebSocket connection can send a single such frame to exhaust the BEAM node's memory and trigger an OOM kill.

This vulnerability requires both Bandit's server-level websocket_options.compress and the per-upgrade compress: true option passed to WebSockAdapter.upgrade/4 to be enabled. Stock Phoenix and LiveView applications are not affected as they default to compress: false.

This issue affects bandit: from 0.5.9 before 1.11.0.

AnalysisAI

Memory exhaustion in Bandit WebSocket server (versions 0.5.9 through 1.10.x) allows unauthenticated remote attackers to crash BEAM nodes via compression bombs when permessage-deflate is enabled. The inflate/2 function decompresses WebSocket frames without output-size limits, enabling attackers to send tiny compressed payloads (~1024:1 ratio) that expand to gigabyte-scale heap allocations. Vendor-released patch available (version 1.11.0). EPSS data not available; no public exploit identified at time of analysis. Exploitation requires non-default configuration (both server-level compress and per-upgrade compress: true options enabled), making stock Phoenix/LiveView applications unaffected.

Technical ContextAI

Bandit is an Elixir-based HTTP/WebSocket server built on the BEAM VM. The vulnerability exists in the WebSocket permessage-deflate compression extension (RFC 7692) implementation. The vulnerable code path in lib/bandit/websocket/permessage_deflate.ex:inflate/2 calls Erlang's :zlib.inflate/2 to decompress incoming frames, then materializes the entire output via IO.iodata_to_binary/1 without checking decompressed size. While websocket_options.max_frame_size caps the on-the-wire (compressed) size, it doesn't limit post-decompression output. This is a classic CWE-770 (Allocation of Resources Without Limits) issue-specifically a 'zip bomb' or 'compression bomb' attack against streaming decompression. The BEAM VM allocates memory for the entire decompressed binary in the connection process before application handlers execute. Attackers craft frames with highly compressible data (uniform byte sequences) that compress at ratios exceeding 1000:1, staying under wire-size limits while forcing multi-gigabyte heap allocations. The fix (commit 8156921a) introduces :zlib.safeInflate/2 with a max_inflate_ratio parameter (default 25:1) that incrementally checks decompressed output size and aborts with error code 1009 if the ratio is exceeded.

RemediationAI

Upgrade to Bandit version 1.11.0 or later, which implements safe decompression with bounded inflation ratios (vendor-released patch confirmed via commit 8156921a51e684a951221da7bc30a70a022f722e at https://github.com/mtrudel/bandit/commit/8156921a51e684a951221da7bc30a70a022f722e). The fix introduces :zlib.safeInflate/2 with a default max_inflate_ratio of 25:1, aborting decompression with WebSocket close code 1009 if exceeded. For deployments unable to upgrade immediately, disable WebSocket permessage-deflate compression by setting websocket_options.compress to false at the server level and ensuring compress: false in all WebSockAdapter.upgrade/4 calls-this eliminates the attack vector entirely with no performance penalty for most applications (stock Phoenix/LiveView already use this safe default). Note that disabling compression may increase bandwidth consumption for applications intentionally using compression for large message payloads; quantify this trade-off before applying. If compression is business-critical and upgrade is delayed, implement application-layer rate limiting on WebSocket connection establishment and consider per-source-IP connection limits to slow multi-connection amplification attacks, though this only mitigates not prevents single-connection exploitation. Full advisory and patch details at GHSA-frh3-6pv6-rc8j.