UBUNTU-CVE-2026-65059: Medium severity ubuntu/libfurl-perl vulnerability
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Read responses using Furl's write_file or write_code interfaces so the response is streamed rather than held in memory.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using affected Furl versions that receive HTTP responses are exposed when a server can return a gzip, x-gzip, or deflate-encoded response. This includes clients that did not explicitly request compressed content, because Furl inflates such responses regardless.
What does an attacker need to exploit it?
An attacker needs to control a responding server or be able to modify traffic on a plain HTTP connection. They can send a small compressed response that expands without bound in memory, potentially exhausting memory and terminating the client process.
What can be done if an update is not immediately available?
Use Furl response handling through write_file or write_code where possible, because those response bodies are streamed rather than retained in memory. The provided information indicates there is no option to impose a decompressed-size limit.