ffuf denial of service (OOM) via HTTP response decompression bomb

ffuf is a fast web fuzzer written in Go. Prior to 2.2.0, ffuf allows a malicious target server to cause an out-of-memory denial of service because the response size guard in pkg/runner/simple.go checks only the compressed Content-Length while io.ReadAll reads gzip, brotli, deflate, transparently decompressed, or chunked response bodies without a decompressed-size bound. This issue is fixed in version 2.2.0.

ffuf is a fast web fuzzer written in Go. Prior to 2.2.0, ffuf allows a malicious target server to cause an out-of-memory denial of service because the response size guard in pkg/runner/simple.go checks only the compressed Content-Length while io.ReadAll reads gzip, brotli, deflate, transparently decompressed, or chunked response bodies without a decompressed-size bound. This issue is fixed in version 2.2.0.

ffuf is a fast web fuzzer written in Go. Prior to 2.2.0, ffuf allows a malicious target server to cause an out-of-memory denial of service because the response size guard in pkg/runner/simple.go checks only the compressed Content-Length while io.ReadAll reads gzip, brotli, deflate, transparently decompressed, or chunked response bodies without a decompressed-size bound. This issue is fixed in version 2.2.0.

### Summary A malicious or attacker-controlled target server can crash ffuf with an out-of-memory condition by returning a compressed HTTP response that decompresses to a very large body (a decompression bomb). This works against default usage with no special flags. ### Details The response body size guard in `pkg/runner/simple.go` only checks the server-supplied `Content-Length` header, which reflects the *compressed* size and is absent for chunked responses or when Go's `net/http` transport transparently decompresses the body. After that check, `io.ReadAll` reads the entire *decompressed* stream into memory with no upper bound, so a small compressed body that expands to gigabytes causes unbounded allocation and the process is terminated by the OS OOM killer. The guard is bypassed in three independent ways: 1. **gzip (default configuration):** the transport requests gzip on its own and transparently decompresses the response, stripping `Content-Encoding` and `Content-Length`, so the size check is skipped and the already-decoded body is read unbounded. 2. **brotli/deflate (or gzip with headers preserved):** `Content-Length` reflects the small compressed size and passes the check; the body is then manually decompressed into an unbounded `io.ReadAll`. 3. **chunked transfer encoding:** no `Content-Length` header is present, so the numeric parse fails and the check is skipped entirely. ### Impact Denial of service against the operator running ffuf. A single hostile endpoint can OOM-kill ffuf on a default invocation such as `ffuf -u http://target/FUZZ -w wordlist.txt`, discarding all in-memory scan results. Because the crash recurs on every attempt against that target, a server can effectively make itself immune to ffuf-based content discovery. There is no confidentiality or integrity impact; only the availability of the scanning process is affected. CVSS 3.1 base score 7.5 (`AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H`), CWE-409 (Improper Handling of Highly Compressed Data). ### Patches Fixed in **ffuf 2.2.0** (https://github.com/ffuf/ffuf/releases/tag/v2.2.0) via https://github.com/ffuf/ffuf/pull/897. The response body read is now bounded with `io.LimitReader` to the existing 5 MB download cap regardless of `Content-Encoding`, chunked framing, or transport-level decompression; responses exceeding the cap are dropped rather than read into memory. Upgrade to 2.2.0 or later. ### Workarounds There is no configuration flag that fully mitigates this in affected versions. Until upgrading, limit ffuf usage against untrusted or attacker-influenced targets. Upgrading to 2.2.0 is the fix. ### Credits Reported by **João Tricta** (Hakai Offensive Security).

ffuf denial of service (OOM) via HTTP response decompression bomb in github.com/ffuf/ffuf