CVE-2026-73232 in ffuf
Summary
by MITRE • 08/11/2026
ffuf is a fast web fuzzer written in Go. Prior to 2.2.0, ffuf allows a malicious target server to cause an out-of-memory denial of service because the response size guard in pkg/runner/simple.go checks only the compressed Content-Length while io.ReadAll reads gzip, brotli, deflate, transparently decompressed, or chunked response bodies without a decompressed-size bound. This issue is fixed in version 2.2.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/11/2026
The ffuf web fuzzer vulnerability represents a critical denial of service weakness that emerged from improper handling of compressed HTTP responses. This flaw existed in versions prior to 2.2.0 and stemmed from a fundamental mismatch between response size validation and actual data processing mechanisms. The vulnerability operates through a specific technical pathway where the application's size guard mechanism in pkg/runner/simple.go only validates the compressed Content-Length header value while the underlying io.ReadAll function processes decompressed content without any size limitations.
The root cause of this vulnerability lies in the asymmetric approach to response handling where compression metadata is checked but decompressed content is not bounded. When a malicious server responds with a small compressed payload that expands to enormous decompressed size, the application consumes excessive memory resources during the decompression process. This behavior creates a significant operational risk as attackers can craft responses that trigger memory exhaustion on the fuzzing system. The vulnerability aligns with CWE-400 which classifies unchecked resource consumption and specifically addresses the lack of bounds checking for decompressed data.
From an attack perspective, this vulnerability enables adversaries to perform resource exhaustion attacks against ffuf instances by leveraging compression algorithms that can inflate small payloads into massive responses. The impact extends beyond simple denial of service as it can potentially crash the entire fuzzing operation or cause system instability. The issue manifests when ffuf processes HTTP responses containing gzip, brotli, deflate, or chunked encoding without enforcing decompressed size limits. This creates a scenario where memory allocation scales exponentially with response compression ratios rather than linearly with compressed sizes.
The fix implemented in version 2.2.0 addresses this by introducing proper bounds checking for decompressed response sizes, ensuring that the validation mechanism accounts for both compressed and decompressed data characteristics. Security practitioners should consider this vulnerability within the context of the ATT&CK framework's resource exhaustion tactics where adversaries seek to consume system resources to disrupt service availability. Organizations using ffuf for web application security testing must prioritize updating to version 2.2.0 or later to prevent exploitation of this memory consumption flaw that could compromise their security testing infrastructure.
The vulnerability demonstrates the importance of comprehensive input validation beyond simple header checks and highlights how compression algorithms can introduce unexpected resource consumption patterns in network applications. This issue affects not only ffuf's operational stability but also represents a broader class of problems where transparent decompression processes lack appropriate size constraints, making it a critical consideration for any application processing potentially malicious compressed content from external sources.