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

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 () via . The response body read is now bounded with to the existing 5 MB download cap regardless of , chunked framing, or transport-level decompression; responses exceeding the cap are dropped rather than read into memory. Upgrade to 2.2.0 or later.