Snyk has a proof-of-concept or detailed explanation of how to exploit this vulnerability.
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applicationsUpgrade bandit to version 1.14.0 or higher.
bandit is a HTTP server for Plug and WebSock apps.
Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via chunked HTTP/1.1 body reassembly in do_read_chunk in lib/bandit/http1_request.ex. When a client sends a chunked request body composed of many small chunks, the function accumulates each chunk into an iolist before converting the entire structure to a binary via IO.iodata_to_binary/1, causing memory consumption many times larger than the actual body size and sustained CPU usage during the conversion. An unauthenticated remote attacker can send a single request with a large number of one-byte chunks to exhaust server memory and CPU.
1. Run Bandit with a Plug that calls `Plug.Conn.read_body(conn, length: 1_000_000, read_length: 1_000_000)`.
2. Send `POST /` with `Transfer-Encoding: chunked` and a body of 1,000,000 chunks of `1\r\nA\r\n`, followed by `0\r\n\r\n`.
3. When `read_body` returns the 1,000,000 body bytes, the handler process holds about 48 MB and BEAM memory has grown by about 55 MB, for 6 MB sent.
Note: The PoC uses a Plug application running on Bandit that calls Plug.Conn.read_body/2 with a 1 MB length limit, receiving a chunked POST body of 1,000,000 single-byte chunks.