CVE-2026-73232

ffuf, a widely used Go-based web fuzzer, can be crashed by any server it is pointed at: its response-body size guard trusts the server-supplied Content-Length header, which reflects the compressed size, is absent for chunked responses, and is stripped when Go's HTTP transport transparently decompresses gzip, after which the fully decompressed body is read into memory with io.ReadAll and no upper bound. An attacker controlling the target host can return a tiny compressed response that expands to gigabytes, triggering unbounded allocation and an OS OOM kill of the ffuf process on a completely default invocation such as ffuf -u http://target/FUZZ -w wordlist.txt. The attacker gains denial of service against the scanning operator: in-memory scan results are lost on crash, and because the crash recurs on every attempt, a hostile server can effectively make itself immune to ffuf-based content discovery; there is no confidentiality or integrity impact. Anyone running ffuf before 2.2.0 against untrusted or attacker-influenced targets is affected; the flaw impacts the operator's tooling, not the scanned applications. No exploitation is currently known: there is no public proof of concept, the issue is not in CISA KEV, and EPSS estimates a 0.4% probability of exploitation within 30 days.

What to do: Upgrade to ffuf 2.2.0 or later, which bounds the response-body read to the existing 5 MB download cap regardless of content encoding, chunked framing, or transport-level decompression, and drops oversized responses instead of reading them into memory. Until upgraded, avoid pointing ffuf at untrusted or attacker-controlled targets, or run it under a memory cap (ulimit or container limit) to contain OOM kills, keeping in mind in-memory results are lost if the process is killed. No configuration flag fully mitigates the flaw in affected versions.