Description
During a review of curl's handling of response decompression, it was noticed that no limit exists on the final uncompressed data volume from compressed HTTP replies. Instead of setting constraints, the current design allows indefinite expansion during processing. This absence of limits could lead to excessive memory use under certain conditions. Rather than imposing caps by default, the system trusts input without internal safeguards. As a result, malicious payloads might trigger uncontrolled growth in output size.
In lib/content_encoding.c, decompression functions like inflate_stream run in loops using a fixed buffer yet fail to monitor total output size. Consequently, one tiny compressed input may expand into excessive memory usage. Although designed for efficiency, these routines lack limits on expanded data volume. Therefore, malicious servers could trigger disproportionate resource consumption during processing.
This behavior appears using standard curl settings, without needing extra configurations.
Proof of Concept:
I’ve included a PDF with a complete, repeatable proof of concept
curl version along with its setup
a basic gzip compression trap host
curl run using standard setup
noticed rise in RSS while unpacking data
important parts of the code in lib/content_encoding.c
The proof demonstrates a ~48 KB compressed reply grows to around 50 MB in memory prior to disposal.
## Impact
A bad server might make curl use excessive memory by sending a compressed file that expands drastically, which could fill up system RAM and stop normal operations. This happens because the --max-filesize flag only limits downloaded data size but doesn't control how big files become after unpacking.
Suggested Fix (high level):
Set a changeable or fixed maximum for the uncompressed data size, then stop unpacking if that cap is passed.
In lib/content_encoding.c, decompression functions like inflate_stream run in loops using a fixed buffer yet fail to monitor total output size. Consequently, one tiny compressed input may expand into excessive memory usage. Although designed for efficiency, these routines lack limits on expanded data volume. Therefore, malicious servers could trigger disproportionate resource consumption during processing.
This behavior appears using standard curl settings, without needing extra configurations.
Proof of Concept:
I’ve included a PDF with a complete, repeatable proof of concept
curl version along with its setup
a basic gzip compression trap host
curl run using standard setup
noticed rise in RSS while unpacking data
important parts of the code in lib/content_encoding.c
The proof demonstrates a ~48 KB compressed reply grows to around 50 MB in memory prior to disposal.
## Impact
A bad server might make curl use excessive memory by sending a compressed file that expands drastically, which could fill up system RAM and stop normal operations. This happens because the --max-filesize flag only limits downloaded data size but doesn't control how big files become after unpacking.
Suggested Fix (high level):
Set a changeable or fixed maximum for the uncompressed data size, then stop unpacking if that cap is passed.
Basic Information
ID
H1:3471553
Published
Dec 19, 2025 at 07:22
Modified
Dec 21, 2025 at 01:44