GHSA-jcvh-xf52-2cwm: High severity go/github.com/ffuf/ffuf vulnerability

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).