GHSA-JCVH-XF52-2CWM
Vulnerability from github – Published: 2026-09-03 18:02 – Updated: 2026-09-03 18:02Summary
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:
- gzip (default configuration): the transport requests gzip on its own and transparently decompresses the response, stripping
Content-EncodingandContent-Length, so the size check is skipped and the already-decoded body is read unbounded. - brotli/deflate (or gzip with headers preserved):
Content-Lengthreflects the small compressed size and passes the check; the body is then manually decompressed into an unboundedio.ReadAll. - chunked transfer encoding: no
Content-Lengthheader 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).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.1.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/ffuf/ffuf/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/ffuf/ffuf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-73232"
],
"database_specific": {
"cwe_ids": [
"CWE-409"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T18:02:09Z",
"nvd_published_at": "2026-08-11T20:18:48Z",
"severity": "HIGH"
},
"details": "### Summary\n\n 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\n bomb). This works against default usage with no special flags.\n\n ### Details\n\n 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\u0027s\n `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\n expands to gigabytes causes unbounded allocation and the process is terminated by the OS OOM killer.\n\n The guard is bypassed in three independent ways:\n\n 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\n skipped and the already-decoded body is read unbounded.\n 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\n `io.ReadAll`.\n 3. **chunked transfer encoding:** no `Content-Length` header is present, so the numeric parse fails and the check is skipped entirely.\n\n ### Impact\n\n 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\n 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\n 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).\n\n ### Patches\n\n 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\n 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.\n\n ### Workarounds\n\n 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.\n\n ### Credits\n\n Reported by **Jo\u00e3o Tricta** (Hakai Offensive Security).",
"id": "GHSA-jcvh-xf52-2cwm",
"modified": "2026-09-03T18:02:09Z",
"published": "2026-09-03T18:02:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ffuf/ffuf/security/advisories/GHSA-jcvh-xf52-2cwm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73232"
},
{
"type": "WEB",
"url": "https://github.com/ffuf/ffuf/pull/897"
},
{
"type": "WEB",
"url": "https://github.com/ffuf/ffuf/commit/fb0da86c60443b0dddbc9a86e91e3a6487dff79b"
},
{
"type": "PACKAGE",
"url": "https://github.com/ffuf/ffuf"
},
{
"type": "WEB",
"url": "https://github.com/ffuf/ffuf/releases/tag/v2.2.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "ffuf denial of service (OOM) via HTTP response decompression bomb"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.