CVE-2026-73232: ffuf Web Fuzzer DOS Vulnerability

CVE-2026-73232 Overview

CVE-2026-73232 is a denial of service vulnerability in ffuf, a fast web fuzzer written in Go. Versions prior to 2.2.0 allow a malicious target server to trigger an out-of-memory (OOM) condition on the fuzzing client. The response size guard in pkg/runner/simple.go checks only the compressed Content-Length header. However, io.ReadAll transparently decompresses gzip, brotli, deflate, or chunked response bodies without enforcing a decompressed-size bound. An attacker-controlled server can therefore return a small compressed payload that expands into gigabytes of memory. The vulnerability is classified as an improper handling of highly compressed data (data amplification) issue under [CWE-409].

Critical Impact
A malicious HTTP server can crash ffuf clients through a decompression bomb, disrupting reconnaissance and automated security testing workflows.

Affected Products

ffuf versions prior to 2.2.0
Automation pipelines and CI/CD jobs that invoke ffuf against untrusted targets
Bug bounty and offensive security workflows using vulnerable ffuf releases

Discovery Timeline

2026-08-11 - CVE-2026-73232 published to NVD
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-73232

Vulnerability Analysis

ffuf issues HTTP requests during web fuzzing and reads the response body to compute size, word, and line metrics. The client applies a size guard against the Content-Length header before reading. This check runs against the compressed length reported by the server, not the decompressed payload size. When the server advertises Content-Encoding: gzip, br, or deflate, ffuf wraps the response body in a corresponding decompression reader. The subsequent io.ReadAll call then materializes the fully decompressed content into memory with no upper bound.

An attacker who controls a web server the operator targets can return a small compressed payload, for example a highly compressible stream of null bytes, that expands to gigabytes. The result is memory exhaustion and process termination on the fuzzing host.

Root Cause

The root cause is a mismatch between the size validation layer and the read layer. The guard validates compressed byte counts while the reader consumes decompressed bytes. Chunked transfer encoding compounds the issue because no Content-Length header is present to gate the read at all. The class of defect maps to [CWE-409] Improper Handling of Highly Compressed Data.

Attack Vector

The attack is remote and requires no authentication or user interaction beyond the operator directing ffuf at the attacker-controlled endpoint. A malicious host returns responses with Content-Encoding: gzip, br, or deflate containing a decompression bomb, or uses chunked encoding to stream unbounded content. ffuf allocates memory until the operating system kills the process.

 		resp.Request.Raw = string(rawreq)
 		resp.Raw = string(rawresp)
 	}
-	var bodyReader io.ReadCloser
-	if httpresp.Header.Get("Content-Encoding") == "gzip" {
-		bodyReader, err = gzip.NewReader(httpresp.Body)
-		if err != nil {
-			// fallback to raw data
-			bodyReader = httpresp.Body
-		}
-	} else if httpresp.Header.Get("Content-Encoding") == "br" {
-		bodyReader = io.NopCloser(brotli.NewReader(httpresp.Body))
-		if err != nil {
-			// fallback to raw data
-			bodyReader = httpresp.Body
-		}
-	} else if httpresp.Header.Get("Content-Encoding") == "deflate" {
+	var bodyReader io.Reader = httpresp.Body
+	switch httpresp.Header.Get("Content-Encoding") {
+	case "gzip":
+		if zr, zerr := gzip.NewReader(httpresp.Body); zerr == nil {
+			bodyReader = zr
+		} // else: fall back to the raw (undecoded) body
+	case "br":
+		bodyReader = brotli.NewReader(httpresp.Body)
+	case "deflate":
 		bodyReader = flate.NewReader(httpresp.Body)
-		if err != nil {
-			// fallback to raw data
-			bodyReader = httpresp.Body

Source: ffuf commit fb0da86. The patch refactors decoding and later bounds the reader with a maximum decompressed size in pkg/runner/simple.go.

Detection Methods for CVE-2026-73232

Indicators of Compromise

Unexpected termination of ffuf processes with out-of-memory kill signals in system logs such as dmesg or journalctl
Sudden memory pressure on hosts running ffuf against external targets
ffuf runs returning premature exits or truncated result files during scans of untrusted endpoints

Detection Strategies

Inventory ffuf binaries across scanning hosts, CI runners, and analyst workstations and flag versions below 2.2.0
Correlate ffuf process crashes with responses that include Content-Encoding: gzip, br, or deflate headers from external targets
Monitor egress proxy logs for compressed responses with unusually high compression ratios delivered to fuzzing hosts

Monitoring Recommendations

Enable per-process memory ceilings via cgroups or ulimit on hosts running ffuf and alert on breaches
Log OOM killer events from the Linux kernel and forward them to a central SIEM for correlation
Track ffuf version telemetry in configuration management tooling to identify unpatched deployments

How to Mitigate CVE-2026-73232

Immediate Actions Required

Upgrade ffuf to version 2.2.0 or later on every host that runs the tool
Audit automation pipelines and container images that bundle ffuf and rebuild with the patched release
Avoid pointing pre-2.2.0 ffuf at untrusted or attacker-influenced targets until the upgrade is complete

Patch Information

The fix ships in ffuf release v2.2.0. The change is implemented in pull request #897 and applied by commit fb0da86. Full details are documented in the GitHub Security Advisory GHSA-jcvh-xf52-2cwm. The patch bounds the decompressed response body using an io.LimitReader so decompression cannot exceed a configured maximum.

Workarounds

Run ffuf inside a memory-constrained container or systemd scope that caps resident memory to a safe ceiling
Restrict ffuf to trusted internal targets until the upgrade to 2.2.0 is complete
Strip or block Content-Encoding headers via an outbound proxy so ffuf receives only raw response bodies

bash

# Upgrade ffuf and enforce a memory ceiling on the process
go install github.com/ffuf/ffuf/v2@v2.2.0

# Optional: cap memory using systemd-run to contain any residual risk
systemd-run --scope -p MemoryMax=512M ffuf -w wordlist.txt -u https://target.example/FUZZ