CVE-2026-65059: Furl versions through 3.15 for Perl allow memory exhaustion via unbounded decompression of HTTP responses
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 writefile or writecode 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.
Affected Software
Event History
Frequently Asked Questions
Which applications are realistically exposed to this issue?
Perl applications using Furl through version 3.15 are exposed when they read HTTP response bodies into memory. The risk is greatest when the application fetches content from malicious or untrusted servers, or uses plain HTTP where an attacker can alter responses in transit.
Does an application need to request compressed content for exploitation to work?
No. Furl decompresses responses marked with gzip, x-gzip, or deflate Content-Encoding even if the request did not ask for compression.
What can be done if updating is not immediately possible?
Use write_file or write_code to consume responses, because these modes stream response data instead of retaining the decompressed body in memory. Avoid fetching from untrusted endpoints and avoid plain HTTP connections where possible.
How can I identify potentially affected code?
Look for uses of Furl that retrieve response bodies into strings or otherwise process the complete response in memory. Requests that use write_file or write_code are streamed and do not hold the full decompressed response in memory.