Bandit
Monthly
Bandit's HTTP/2 request body reader amplifies memory use, letting an unauthenticated remote client make a server hold roughly 5 to 8 times the body bytes it sends in stream process memory. Affected are versions from 0.3.1 before 1.14.1 on listeners where HTTP/2 is enabled and the route's Plug actually reads the request body, which includes anything behind Plug.Parsers for POST, PUT and PATCH. A public proof-of-concept reference exists; it is not verified as working exploit code, and no active exploitation has been confirmed. Vendor-released patch: 1.14.1.
Unauthenticated remote CPU exhaustion in mtrudel Bandit's HTTP/2 server (versions before 1.14.0) is achievable by holding thousands of response streams blocked on the connection send window and then sending tiny SETTINGS or stream-0 WINDOW_UPDATE frames. Each such frame makes the server retry every blocked send via do_pending_sends/2, producing O(n²) list operations; the advisory's verified PoC measured 133 ms for a single 9-byte SETTINGS frame with 3,000 blocked streams. The issue is remotely exploitable without authentication or user interaction and is prioritized this_week; the supplied data does not confirm active exploitation, and a public proof-of-concept is included in the advisory.
Unbounded per-connection memory and CPU growth in the Elixir Bandit HTTP/2 server (0.3.6 up to 1.14.0) lets an unauthenticated remote client advertise a SETTINGS_HEADER_TABLE_SIZE of up to 2^32-1, which Bandit applies to its HPACK encoder table with no server-side cap; every response header is then stored into that oversized table and never evicted, so the encoding cost of each response grows linearly and the connection's total cost grows quadratically. No authentication or user interaction is required (PR:N/UI:N), the effect is purely availability (C:N/I:N/A:H, scored 8.7 under CVSS 4.0 and assessed as AV:N/AC:L/PR:N/UI:N/A:H under CVSS 3.1), and it only bites while a connection is kept alive and busy with cheap requests to endpoints whose response headers vary per request. It is not confirmed actively exploited (CISA KEV), but the vendor advisory documents a public proof-of-concept procedure; treat it as a this-week priority rather than an emergency, since capping requests per connection or upgrading to 1.14.0 removes the growth.
Unauthenticated remote attackers can exhaust BEAM node memory on default-configured mtrudel Bandit HTTP/2 servers (0.3.3 before 1.14.0) by sending a small HPACK HEADERS block that expands into a huge joined cookie value before any plug code executes. Concurrent streams multiply the allocation, and the vendor advisory includes a public proof-of-concept description; it is not verified as working exploit code. Bandit 1.14.0 is the vendor-released fix, while setting a finite max_header_list_size or disabling HTTP/2 removes the vulnerable path.
HTTP/2 resource-limit bypass in the Elixir Bandit web server (1.9.0 through 1.13.x) lets an unauthenticated remote client exceed the configured max_concurrent_streams and max_requests caps by packing multiple HEADERS frames into a single TCP write where one frame raises a StreamError, causing the handler to continue from pre-chunk connection state. Because stream counts, last_stream_id, rapid-reset timestamps and the HPACK decoder state are all rolled back while the already-started Plug calls keep running, an attacker can drive roughly five times the intended number of concurrent Plug invocations per connection (50 running against a limit of 10 in the reporter's test), exhausting server processes, CPU and memory. Impact is strictly availability - no confidentiality or integrity loss - HTTP/2 with a finite max_concurrent_streams is the default for Bandit's TLS/h2 listeners, no public exploit code is confirmed, and a vendor patch is available.
Unauthenticated remote denial of service in the Elixir HTTP server Bandit (mtrudel/bandit) from 0.1.0 before 1.14.0 lets a single remote attacker exhaust server memory and CPU with one HTTP/1.1 request whose chunked body is composed of a very large number of 1-byte chunks. Because the chunked reader keeps every chunk as its own cons cell and binary term until IO.iodata_to_binary/1 joins them, and the :length option of read_body/2 counts only data bytes, the vendor's reproduction shows 48 MB of 1-byte chunks growing one handler process to roughly 500 MB and consuming about 6 seconds of CPU - a ~48x amplification over the payload sent - and the amplification also occurs against routes that never call read_body, since ensure_completed/1 drains unread bodies on keep-alive connections. HTTP/1.1 is enabled by default, so any default deployment is exposed without authentication or user interaction; the vendor shipped a fix in 1.14.0, there are no reports of exploitation in CISA KEV and no independently confirmed public exploit code, though the advisory does publish detailed reproduction steps.
Unauthenticated remote attackers can consume disproportionate server CPU on Bandit (mtrudel/bandit, Elixir/Erlang) by sending a Content-Length value or a Host/:authority port composed of thousands of digits, which the header integer parser processes in quadratic time before any range check. Over HTTP/2 the cost is amplified because a 4,000-digit value can be stored once in the HPACK dynamic table and replayed cheaply across thousands of new streams; the advisory's proof-of-concept sent roughly 124 KB that kept the server busy for 27.9 seconds. Both HTTP/1 and HTTP/2 deployments are affected at default configuration, versions 1.0.0-pre.7 up to but not including 1.14.0. The advisory includes a public PoC reference that is not independently verified as working exploit code; there is no CISA KEV listing or other indication of active exploitation, and the vendor has released 1.14.0 as the fix.
Memory exhaustion in the Erlang/Elixir Bandit web server (mtrudel/bandit 1.11.0 up to but not including 1.14.0) lets an unauthenticated remote client drive a single WebSocket connection to roughly 150 times the configured max_fragmented_message_size, about 1.2-1.4 GB at the 8 MB default. Bandit counts only payload bytes against the fragment limit while storing every non-final 1-byte continuation frame as its own list cell costing about 150-170 bytes of BEAM heap, and ping frames injected between fragments keep the connection alive past the idle timeout. Any deployment that accepts WebSocket upgrades with default settings is exposed, notably Phoenix LiveView and Phoenix Channels applications; the vendor advisory includes reproduction steps (a public PoC reference exists; it is not verified as working exploit code), no public exploit tooling or active exploitation is indicated by the available data, and the vendor has released a fix in 1.14.0.
Unauthenticated remote attackers can hold Bandit HTTP/2 stream processes and the request-body reads they are servicing open indefinitely by sending small WINDOW_UPDATE or empty SETTINGS frames before the read timeout expires, affecting Bandit versions from 1.4.0 before 1.14.0 with HTTP/2 enabled and routes that read request bodies. Impact is availability only: request handlers and associated resources can be occupied across many streams and connections, creating denial-of-service conditions; confidentiality and integrity are not affected. Vendor-released patch: 1.14.0; no public exploit identified at time of analysis, and this is a genuine availability risk that warrants prompt attention, though not an emergency.
Unauthenticated remote memory exhaustion in the Elixir Bandit HTTP/2 server lets a single client consume all memory on the BEAM node by sending DATA frames that the server never refuses. Affected are bandit releases from 0.3.1 up to, but not including, 1.14.0 when HTTP/2 is enabled, which is the default. The attacker stalls a stream by requesting a response larger than the 65,535-byte initial window and withholding WINDOW_UPDATE, then floods small DATA frames that queue unread in the stream process mailbox; a public proof-of-concept procedure is described in the vendor advisory, but it is not confirmed as working exploit code, and no CISA KEV entry or other active-exploitation signal is present in the supplied data.
Uncontrolled HTTP/2 flow-control resource consumption in mtrudel/bandit 1.4.0 and later lets an unauthenticated remote peer hold server-side stream processes - together with their Plug conn state and any resource held mid-response - alive indefinitely by dripping small WINDOW_UPDATE frames just before each 15-second send deadline expires. Because both the connection-level (finish_data/5 re-queues the pending send with a fresh expires_at) and stream-level (send_data/3 recurses and re-arms read_timeout) deadline resets fire on partial progress, and the two paths are independent, an attacker can repeat the trickle across many streams and connections to exhaust processes and memory in a denial of service reachable with no authentication and no user interaction (CVSS 4.0 base 8.7; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). No public exploit code or confirmed active exploitation was identified at time of analysis; an upstream fix commit is available and the issue is limited to bandit 1.4.0 and later.
CPU exhaustion in bandit 1.11.0 to 1.12.0 allows unauthenticated remote denial-of-service via WebSocket fragment reassembly. An attacker can send millions of tiny continuation frames per connection, triggering quadratic (O(n²)) buffer length recalculation that pins a CPU core for minutes to hours without requiring any authentication. No active exploitation has been confirmed (KEV), but a public proof-of-concept exists, and the EPSS score is low (0.39%).
Unauthenticated remote denial of service in mtrudel Bandit (Elixir HTTP server) versions 1.6.1 through 1.11.0 lets any client pin a worker process indefinitely by sending an RFC 9112-conformant chunked request that ends with trailer fields. Because the HTTP/1 chunked decoder only terminates on a bare '0\r\n\r\n' and never consumes trailers, a handful of concurrent connections exhausts the worker pool and makes the server unresponsive to all traffic. Publicly available exploit code exists (a self-contained PoC ships in the GHSA advisory), though the flaw is not listed in CISA KEV and EPSS is low (0.47%).
Unauthenticated remote denial of service in Bandit (the Elixir HTTP/1 web server for Phoenix/Plug applications) versions 1.4.0 through 1.11.0 allows an attacker to crash the entire BEAM VM by sending a single Transfer-Encoding: chunked POST with an oversized body. The chunked-body reader ignores the application's configured :length cap (e.g. Plug.Parsers' default 8 MB), buffering the whole body in memory until the OS OOM killer terminates the process. Publicly available exploit code exists (a self-contained PoC ships in the GHSA advisory), though EPSS remains low at 0.31% and it is not listed in CISA KEV.
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.
Memory exhaustion in Bandit WebSocket server (versions 0.5.0 through 1.10.x) allows unauthenticated remote attackers to trigger denial of service by sending unbounded WebSocket continuation frames without setting the fin flag. The fragment reassembly logic accumulates payloads without checking cumulative message size, bypassing the max_frame_size limit which only applies to individual frames. Applications using Phoenix Channels or LiveView over Bandit expose this attack surface on any WebSocket endpoint. Patch available in version 1.11.0 introduces max_fragmented_message_size parameter (default 8MB). No public exploit code identified at time of analysis, but trivial to reproduce with standard WebSocket libraries.
Bandit, the pure-Elixir HTTP/WebSocket server, keeps running a WebSock application's handler code after the server has initiated a close, so a remote client that ignores the Close frame can still reach handle_in/2 and handle_info/2 with the state from the {:stop, ...} tuple. Versions 0.5.1 through 1.14.0 are affected (fixed in 1.14.0), and the practical impact lands on WebSock applications that use {:stop, ...} to enforce authorization - a client refused in init/1 after a failed token check, or a kicked/banned user (including Phoenix's :socket_drain path), can keep invoking sensitive actions until it sends Close, TCP drops, or the idle timeout fires, and each client frame resets that timeout. The vendor advisory includes a step-by-step proof-of-concept walkthrough; a public PoC reference exists, but it is not verified as working exploit code, and there is no confirmed active exploitation (CISA KEV).
HTTP request smuggling in the Elixir Bandit web server (1.12.4 up to but not including 1.14.0) lets an unauthenticated remote attacker slip a second request past a front-end proxy by embedding a bare LF in a chunk extension. Because Bandit's HTTP/1.1 chunked reader treats the chunk-size line as everything up to the first CRLF and discards anything after ';' without validating it against the RFC 9112 chunk-ext grammar, Bandit can end a body early and dispatch a trailing 'GET /admin' as its own pipelined request, while a proxy that terminates the size line at the bare LF forwards the same bytes as a single POST. Impact is bounded by a hard precondition: there must be a front-end proxy that treats a bare LF as a line ending and forwards chunked bodies unchanged (the AT:P requirement, outside attacker control) - deployments without such a proxy are not affected. Severity is medium (CVSS 4.0 base 6.3; independently assessed as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N), no CISA KEV entry exists, and the vendor advisory describes a proof-of-concept procedure that is not confirmed as publicly available working exploit code.
Bandit versions 0.6.0 up to (but not including) 1.13.0 pass an attacker-supplied authority from HTTP/1 absolute-form and authority-form request targets straight into conn.host and conn.port without validating it against the RFC 3986 host grammar, so an unauthenticated remote request such as 'GET http://good.example@evil.example/x HTTP/1.1' overrides the Host header that Bandit does check. The real-world impact is narrow and conditional: it only matters when the hosting Elixir/Phoenix application builds absolute URLs from conn.host/conn.port (Plug.Conn.request_url/1, Phoenix URL helpers) and then uses those URLs in a security-relevant way, and because message framing is untouched and no CR or LF byte can reach conn.host, it cannot be turned into request smuggling or CRLF/response-header injection. The vendor rates this CVSS 4.0 6.9 (Medium) with only low integrity impact (VI:L, no confidentiality or availability loss); no public exploit code or confirmed active exploitation has been identified at time of analysis (no public exploit identified at time of analysis).
HTTP request smuggling in mtrudel bandit before version 1.11.0 allows unauthenticated attackers to bypass edge security controls when the application sits behind a proxy that interprets duplicate Content-Length headers differently. The vulnerability stems from Bandit accepting only the first Content-Length header while proxies may use the last value, causing request framing desynchronization that enables smuggling past WAF rules, path-based ACLs, rate limiting, and audit logging. CVSS 6.3 (AV:N/AC:L/AT:P) indicates network-accessible exploitation with some attack timing complexity; no public exploit code or active KEV listing identified at analysis time, but RFC 9112 non-compliance creates a known attack pattern.
Transport-state spoofing in Bandit 1.0.0 through 1.10.x allows unauthenticated remote attackers to forge HTTPS connections over plaintext HTTP by supplying a malicious URI scheme in HTTP/1.1 absolute-form request targets or HTTP/2 :scheme pseudo-headers. The vulnerable determine_scheme/2 function returns client-supplied scheme values verbatim, causing downstream Plug middlewares to make incorrect security decisions: Plug.SSL skips HTTP→HTTPS redirects, secure cookies are transmitted unencrypted, and CSRF/SameSite protections may be bypassed. CVSS 6.3 (network-accessible, low complexity). Vendor patch available (version 1.11.0+).
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.
Bandit's HTTP/2 request body reader amplifies memory use, letting an unauthenticated remote client make a server hold roughly 5 to 8 times the body bytes it sends in stream process memory. Affected are versions from 0.3.1 before 1.14.1 on listeners where HTTP/2 is enabled and the route's Plug actually reads the request body, which includes anything behind Plug.Parsers for POST, PUT and PATCH. A public proof-of-concept reference exists; it is not verified as working exploit code, and no active exploitation has been confirmed. Vendor-released patch: 1.14.1.
Unauthenticated remote CPU exhaustion in mtrudel Bandit's HTTP/2 server (versions before 1.14.0) is achievable by holding thousands of response streams blocked on the connection send window and then sending tiny SETTINGS or stream-0 WINDOW_UPDATE frames. Each such frame makes the server retry every blocked send via do_pending_sends/2, producing O(n²) list operations; the advisory's verified PoC measured 133 ms for a single 9-byte SETTINGS frame with 3,000 blocked streams. The issue is remotely exploitable without authentication or user interaction and is prioritized this_week; the supplied data does not confirm active exploitation, and a public proof-of-concept is included in the advisory.
Unbounded per-connection memory and CPU growth in the Elixir Bandit HTTP/2 server (0.3.6 up to 1.14.0) lets an unauthenticated remote client advertise a SETTINGS_HEADER_TABLE_SIZE of up to 2^32-1, which Bandit applies to its HPACK encoder table with no server-side cap; every response header is then stored into that oversized table and never evicted, so the encoding cost of each response grows linearly and the connection's total cost grows quadratically. No authentication or user interaction is required (PR:N/UI:N), the effect is purely availability (C:N/I:N/A:H, scored 8.7 under CVSS 4.0 and assessed as AV:N/AC:L/PR:N/UI:N/A:H under CVSS 3.1), and it only bites while a connection is kept alive and busy with cheap requests to endpoints whose response headers vary per request. It is not confirmed actively exploited (CISA KEV), but the vendor advisory documents a public proof-of-concept procedure; treat it as a this-week priority rather than an emergency, since capping requests per connection or upgrading to 1.14.0 removes the growth.
Unauthenticated remote attackers can exhaust BEAM node memory on default-configured mtrudel Bandit HTTP/2 servers (0.3.3 before 1.14.0) by sending a small HPACK HEADERS block that expands into a huge joined cookie value before any plug code executes. Concurrent streams multiply the allocation, and the vendor advisory includes a public proof-of-concept description; it is not verified as working exploit code. Bandit 1.14.0 is the vendor-released fix, while setting a finite max_header_list_size or disabling HTTP/2 removes the vulnerable path.
HTTP/2 resource-limit bypass in the Elixir Bandit web server (1.9.0 through 1.13.x) lets an unauthenticated remote client exceed the configured max_concurrent_streams and max_requests caps by packing multiple HEADERS frames into a single TCP write where one frame raises a StreamError, causing the handler to continue from pre-chunk connection state. Because stream counts, last_stream_id, rapid-reset timestamps and the HPACK decoder state are all rolled back while the already-started Plug calls keep running, an attacker can drive roughly five times the intended number of concurrent Plug invocations per connection (50 running against a limit of 10 in the reporter's test), exhausting server processes, CPU and memory. Impact is strictly availability - no confidentiality or integrity loss - HTTP/2 with a finite max_concurrent_streams is the default for Bandit's TLS/h2 listeners, no public exploit code is confirmed, and a vendor patch is available.
Unauthenticated remote denial of service in the Elixir HTTP server Bandit (mtrudel/bandit) from 0.1.0 before 1.14.0 lets a single remote attacker exhaust server memory and CPU with one HTTP/1.1 request whose chunked body is composed of a very large number of 1-byte chunks. Because the chunked reader keeps every chunk as its own cons cell and binary term until IO.iodata_to_binary/1 joins them, and the :length option of read_body/2 counts only data bytes, the vendor's reproduction shows 48 MB of 1-byte chunks growing one handler process to roughly 500 MB and consuming about 6 seconds of CPU - a ~48x amplification over the payload sent - and the amplification also occurs against routes that never call read_body, since ensure_completed/1 drains unread bodies on keep-alive connections. HTTP/1.1 is enabled by default, so any default deployment is exposed without authentication or user interaction; the vendor shipped a fix in 1.14.0, there are no reports of exploitation in CISA KEV and no independently confirmed public exploit code, though the advisory does publish detailed reproduction steps.
Unauthenticated remote attackers can consume disproportionate server CPU on Bandit (mtrudel/bandit, Elixir/Erlang) by sending a Content-Length value or a Host/:authority port composed of thousands of digits, which the header integer parser processes in quadratic time before any range check. Over HTTP/2 the cost is amplified because a 4,000-digit value can be stored once in the HPACK dynamic table and replayed cheaply across thousands of new streams; the advisory's proof-of-concept sent roughly 124 KB that kept the server busy for 27.9 seconds. Both HTTP/1 and HTTP/2 deployments are affected at default configuration, versions 1.0.0-pre.7 up to but not including 1.14.0. The advisory includes a public PoC reference that is not independently verified as working exploit code; there is no CISA KEV listing or other indication of active exploitation, and the vendor has released 1.14.0 as the fix.
Memory exhaustion in the Erlang/Elixir Bandit web server (mtrudel/bandit 1.11.0 up to but not including 1.14.0) lets an unauthenticated remote client drive a single WebSocket connection to roughly 150 times the configured max_fragmented_message_size, about 1.2-1.4 GB at the 8 MB default. Bandit counts only payload bytes against the fragment limit while storing every non-final 1-byte continuation frame as its own list cell costing about 150-170 bytes of BEAM heap, and ping frames injected between fragments keep the connection alive past the idle timeout. Any deployment that accepts WebSocket upgrades with default settings is exposed, notably Phoenix LiveView and Phoenix Channels applications; the vendor advisory includes reproduction steps (a public PoC reference exists; it is not verified as working exploit code), no public exploit tooling or active exploitation is indicated by the available data, and the vendor has released a fix in 1.14.0.
Unauthenticated remote attackers can hold Bandit HTTP/2 stream processes and the request-body reads they are servicing open indefinitely by sending small WINDOW_UPDATE or empty SETTINGS frames before the read timeout expires, affecting Bandit versions from 1.4.0 before 1.14.0 with HTTP/2 enabled and routes that read request bodies. Impact is availability only: request handlers and associated resources can be occupied across many streams and connections, creating denial-of-service conditions; confidentiality and integrity are not affected. Vendor-released patch: 1.14.0; no public exploit identified at time of analysis, and this is a genuine availability risk that warrants prompt attention, though not an emergency.
Unauthenticated remote memory exhaustion in the Elixir Bandit HTTP/2 server lets a single client consume all memory on the BEAM node by sending DATA frames that the server never refuses. Affected are bandit releases from 0.3.1 up to, but not including, 1.14.0 when HTTP/2 is enabled, which is the default. The attacker stalls a stream by requesting a response larger than the 65,535-byte initial window and withholding WINDOW_UPDATE, then floods small DATA frames that queue unread in the stream process mailbox; a public proof-of-concept procedure is described in the vendor advisory, but it is not confirmed as working exploit code, and no CISA KEV entry or other active-exploitation signal is present in the supplied data.
Uncontrolled HTTP/2 flow-control resource consumption in mtrudel/bandit 1.4.0 and later lets an unauthenticated remote peer hold server-side stream processes - together with their Plug conn state and any resource held mid-response - alive indefinitely by dripping small WINDOW_UPDATE frames just before each 15-second send deadline expires. Because both the connection-level (finish_data/5 re-queues the pending send with a fresh expires_at) and stream-level (send_data/3 recurses and re-arms read_timeout) deadline resets fire on partial progress, and the two paths are independent, an attacker can repeat the trickle across many streams and connections to exhaust processes and memory in a denial of service reachable with no authentication and no user interaction (CVSS 4.0 base 8.7; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). No public exploit code or confirmed active exploitation was identified at time of analysis; an upstream fix commit is available and the issue is limited to bandit 1.4.0 and later.
CPU exhaustion in bandit 1.11.0 to 1.12.0 allows unauthenticated remote denial-of-service via WebSocket fragment reassembly. An attacker can send millions of tiny continuation frames per connection, triggering quadratic (O(n²)) buffer length recalculation that pins a CPU core for minutes to hours without requiring any authentication. No active exploitation has been confirmed (KEV), but a public proof-of-concept exists, and the EPSS score is low (0.39%).
Unauthenticated remote denial of service in mtrudel Bandit (Elixir HTTP server) versions 1.6.1 through 1.11.0 lets any client pin a worker process indefinitely by sending an RFC 9112-conformant chunked request that ends with trailer fields. Because the HTTP/1 chunked decoder only terminates on a bare '0\r\n\r\n' and never consumes trailers, a handful of concurrent connections exhausts the worker pool and makes the server unresponsive to all traffic. Publicly available exploit code exists (a self-contained PoC ships in the GHSA advisory), though the flaw is not listed in CISA KEV and EPSS is low (0.47%).
Unauthenticated remote denial of service in Bandit (the Elixir HTTP/1 web server for Phoenix/Plug applications) versions 1.4.0 through 1.11.0 allows an attacker to crash the entire BEAM VM by sending a single Transfer-Encoding: chunked POST with an oversized body. The chunked-body reader ignores the application's configured :length cap (e.g. Plug.Parsers' default 8 MB), buffering the whole body in memory until the OS OOM killer terminates the process. Publicly available exploit code exists (a self-contained PoC ships in the GHSA advisory), though EPSS remains low at 0.31% and it is not listed in CISA KEV.
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.
Memory exhaustion in Bandit WebSocket server (versions 0.5.0 through 1.10.x) allows unauthenticated remote attackers to trigger denial of service by sending unbounded WebSocket continuation frames without setting the fin flag. The fragment reassembly logic accumulates payloads without checking cumulative message size, bypassing the max_frame_size limit which only applies to individual frames. Applications using Phoenix Channels or LiveView over Bandit expose this attack surface on any WebSocket endpoint. Patch available in version 1.11.0 introduces max_fragmented_message_size parameter (default 8MB). No public exploit code identified at time of analysis, but trivial to reproduce with standard WebSocket libraries.
Bandit, the pure-Elixir HTTP/WebSocket server, keeps running a WebSock application's handler code after the server has initiated a close, so a remote client that ignores the Close frame can still reach handle_in/2 and handle_info/2 with the state from the {:stop, ...} tuple. Versions 0.5.1 through 1.14.0 are affected (fixed in 1.14.0), and the practical impact lands on WebSock applications that use {:stop, ...} to enforce authorization - a client refused in init/1 after a failed token check, or a kicked/banned user (including Phoenix's :socket_drain path), can keep invoking sensitive actions until it sends Close, TCP drops, or the idle timeout fires, and each client frame resets that timeout. The vendor advisory includes a step-by-step proof-of-concept walkthrough; a public PoC reference exists, but it is not verified as working exploit code, and there is no confirmed active exploitation (CISA KEV).
HTTP request smuggling in the Elixir Bandit web server (1.12.4 up to but not including 1.14.0) lets an unauthenticated remote attacker slip a second request past a front-end proxy by embedding a bare LF in a chunk extension. Because Bandit's HTTP/1.1 chunked reader treats the chunk-size line as everything up to the first CRLF and discards anything after ';' without validating it against the RFC 9112 chunk-ext grammar, Bandit can end a body early and dispatch a trailing 'GET /admin' as its own pipelined request, while a proxy that terminates the size line at the bare LF forwards the same bytes as a single POST. Impact is bounded by a hard precondition: there must be a front-end proxy that treats a bare LF as a line ending and forwards chunked bodies unchanged (the AT:P requirement, outside attacker control) - deployments without such a proxy are not affected. Severity is medium (CVSS 4.0 base 6.3; independently assessed as CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N), no CISA KEV entry exists, and the vendor advisory describes a proof-of-concept procedure that is not confirmed as publicly available working exploit code.
Bandit versions 0.6.0 up to (but not including) 1.13.0 pass an attacker-supplied authority from HTTP/1 absolute-form and authority-form request targets straight into conn.host and conn.port without validating it against the RFC 3986 host grammar, so an unauthenticated remote request such as 'GET http://good.example@evil.example/x HTTP/1.1' overrides the Host header that Bandit does check. The real-world impact is narrow and conditional: it only matters when the hosting Elixir/Phoenix application builds absolute URLs from conn.host/conn.port (Plug.Conn.request_url/1, Phoenix URL helpers) and then uses those URLs in a security-relevant way, and because message framing is untouched and no CR or LF byte can reach conn.host, it cannot be turned into request smuggling or CRLF/response-header injection. The vendor rates this CVSS 4.0 6.9 (Medium) with only low integrity impact (VI:L, no confidentiality or availability loss); no public exploit code or confirmed active exploitation has been identified at time of analysis (no public exploit identified at time of analysis).
HTTP request smuggling in mtrudel bandit before version 1.11.0 allows unauthenticated attackers to bypass edge security controls when the application sits behind a proxy that interprets duplicate Content-Length headers differently. The vulnerability stems from Bandit accepting only the first Content-Length header while proxies may use the last value, causing request framing desynchronization that enables smuggling past WAF rules, path-based ACLs, rate limiting, and audit logging. CVSS 6.3 (AV:N/AC:L/AT:P) indicates network-accessible exploitation with some attack timing complexity; no public exploit code or active KEV listing identified at analysis time, but RFC 9112 non-compliance creates a known attack pattern.
Transport-state spoofing in Bandit 1.0.0 through 1.10.x allows unauthenticated remote attackers to forge HTTPS connections over plaintext HTTP by supplying a malicious URI scheme in HTTP/1.1 absolute-form request targets or HTTP/2 :scheme pseudo-headers. The vulnerable determine_scheme/2 function returns client-supplied scheme values verbatim, causing downstream Plug middlewares to make incorrect security decisions: Plug.SSL skips HTTP→HTTPS redirects, secure cookies are transmitted unencrypted, and CSRF/SameSite protections may be bypassed. CVSS 6.3 (network-accessible, low complexity). Vendor patch available (version 1.11.0+).
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.