Furl versions through 3.15 for Perl allow memory exhaustion via unbounded decompression of HTTP responses
Furl 3.15 and earlier for Perl can exhaust client memory when a response body sent with gzip, x-gzip or deflate Content-Encoding is held in memory. No fix is listed.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Not reported
Do first: Workaround: Read responses with write_file or write_code so they are streamed rather than held in memory, which avoids the affected condition. The facts list no fix.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 8/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Unclear
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Furl, a Perl HTTP client library (versions through 3.15), is affected. A malicious server or an attacker on an unencrypted HTTP connection can send a small compressed response that expands into a huge amount of data, exhausting the client's memory and crashing the program.
Read the original description
Furl versions through 3.15 for Perl allow memory exhaustion via unbounded decompression of HTTP responses. Furl inflates a response body sent with a gzip, x-gzip or deflate Content-Encoding and appends the output to the response string with no size limit. It does this whether or not the request asked for compression, and no option caps the decompressed size. Responses read with write_file or write_code are streamed rather than held in memory. A malicious server, or an attacker on a plain HTTP connection, can send a small compressed response that expands to exhaust the client's memory and end the process.
What to do
Workaround: Read responses with write_file or write_code so they are streamed rather than held in memory, which avoids the affected condition. The facts list no fix.
Timeline
- CVE published
- First seen by cve.now
- Record last updated
Affected versions
- Furl
through 3.15
Evidence 2
- Report
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-65059
What does this mean?
Furl decompresses a response body sent with gzip, x-gzip or deflate Content-Encoding without any size limit. A very large decompressed response can use up the client's memory and end the process.Source: github.com
Am I affected, and how do I check?
Furl through version 3.15 for Perl is affected. The problem applies when responses are held in memory rather than read with write_file or write_code, which stream the response instead. Check the installed Furl version with perl -MFurl -e 'print $Furl::VERSION'.Source: github.com
What should I do about it?
The facts give no fixed version, so no upgrade target is confirmed. Reading responses with write_file or write_code avoids holding the body in memory.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What if there's no patch?
Read responses with write_file or write_code so they are streamed rather than held in memory, which avoids the affected condition. The facts list no fix.Source: github.com