https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 03:26:24 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-351421 EUVD-2026-351421 https://cve.radiocsirt.org/vuln/euvd-2026-351421 https://cve.radiocsirt.org/vuln/fkie_cve-2026-73232 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-73232 https://cve.radiocsirt.org/vuln/ghsa-jcvh-xf52-2cwm <p><strong>Affected:</strong> Go: github.com/ffuf/ffuf/v2, Go: github.com/ffuf/ffuf</p> <p>### Summary</p> <p>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.</p> <p>### Details</p> <p>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&#39;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.</p> <p>The guard is bypassed in three independent ways:</p> <p>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 skipped and the already-decoded body is read unbounded. 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 `io.ReadAll`. 3. **chunked transfer encoding:** no `Content-Length` header is present, so the numeric parse fails and the check is skipped entirely.</p> <p>### Impact</p> <p>Denial of service against the operator running f…</p> <p><strong>Affected:</strong> Go: github.com/ffuf/ffuf/v2, Go: github.com/ffuf/ffuf</p> <p>### Summary</p> <p>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.</p> <p>### Details</p> <p>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&#39;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.</p> <p>The guard is bypassed in three independent ways:</p> <p>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 skipped and the already-decoded body is read unbounded. 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 `io.ReadAll`. 3. **chunked transfer encoding:** no `Content-Length` header is present, so the numeric parse fails and the check is skipped entirely.</p> <p>### Impact</p> <p>Denial of service against the operator running f…</p> https://cve.radiocsirt.org/vuln/ghsa-jcvh-xf52-2cwm https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-73232 <p><strong>Affected:</strong> Ubuntu:22.04:LTS: ffuf, Ubuntu:Pro:24.04:LTS: ffuf, Ubuntu:26.04:LTS: ffuf</p> <p>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.</p> <p><strong>Affected:</strong> Ubuntu:22.04:LTS: ffuf, Ubuntu:Pro:24.04:LTS: ffuf, Ubuntu:26.04:LTS: ffuf</p> <p>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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-73232