ffuf CVE-2026-73232

ffuf must be executing an active fuzzing run against an HTTP server controlled or compromised by the attacker. The server must return a response with a compressed body (Content-Encoding: gzip, br, or deflate) or a chunked response that the Go transport transparently decodes, where the decompressed size exceeds available process memory. No special ffuf flags or configuration settings are required - default behavior is sufficient. Exploitation is limited by the following factors: the attacker must control the web server being fuzzed (cannot be exploited against a passive ffuf installation); the attack has no effect on confidentiality or integrity; and the impact is scoped to the ffuf process only, not to the underlying host unless the host itself runs out of memory due to the OOM event.

The CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) score accurately reflects the low-complexity, unauthenticated network path, but the real-world threat model is narrower than a typical server-side AV:N vulnerability: ffuf is a client-side tool, so exploitation requires a user to actively fuzz a server controlled by the attacker - the attacker cannot push this attack to arbitrary internet hosts. The impact is confined to availability of the ffuf process itself, not any production system. EPSS data was not provided in the intelligence feed; KEV status is not listed, confirming no known active exploitation campaign. No public exploit code has been identified, though the decompression-bomb technique is well-understood and trivially implementable by any HTTP server operator. The risk is therefore most relevant to security professionals and automated fuzzing pipelines that scan untrusted or adversarial targets without memory-limiting container controls in place.

An attacker operates a web server configured to return a Content-Encoding: gzip response with a small compressed payload (a few kilobytes of compressed zeros) but a decompressed expansion of several gigabytes. When a penetration tester runs ffuf against this server, ffuf's transport either transparently decodes the gzip stream (stripping size headers) or passes it through the manual brotli/deflate decoder path - in both cases, io.ReadAll consumes the expanding stream until the process is killed by the OS OOM killer. The attack requires no interaction beyond the victim choosing the malicious server as a fuzzing target, and the technique is elementary to implement.