Live › vulnerability › CVE-2026-65059
Furl, a Perl HTTP client, inflates gzip and deflate response bodies with no size limit, so the output is held entirely in memory. A malicious server or an on-path attacker on plain HTTP can send a small compressed response that expands enough to exhaust memory and crash the process.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-11-02 17:24 UTC. All times on this page are UTC.
Any Perl application that uses Furl to fetch responses from servers it does not fully trust, or over plain HTTP, and reads the body into memory rather than streaming it with write_file or write_code. Applications that only talk to trusted HTTPS endpoints, or that stream responses to disk, are less exposed. The sources do not state a fixed release.
No product ranges from the sources yet.
cpanm --info Furl or perl -MFurl -e 'print $Furl::VERSION' to read the installed Furl versionFurl usage that fetches responses without write_file or write_code, since those stream the body3.15 are affected; the sources do not name a fixed versionEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-65059")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.