Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: --max-filesize and --compressed
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-users <curl-users_at_lists.haxx.se>
Date: Mon, 2 Mar 2026 10:13:15 +0100
> Am 02.03.2026 um 09:53 schrieb Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>:
>
> Hi team,
>
> Every once in a while someone reports the compression bomb risk with curl and --compressed as a vulnerability. We regularly dismiss that as we believe we document this risk and behavior.
>
> Still, the risk is there: if you use --compressed, a tiny download can be decompressed into a HUGE destination file.
>
> The --max-filesize option does not help here because it sets a limit to the size of the downloaded file, and one of these "bombs" does not have to be a big download.
>
> But maybe we can do better?
>
> Would it make sense to have some kind of limit to the "explosion factor" ? Should perhaps the --max-filesize limit be applied on the uncompressed size as well ? Should there be a new separate option? Or should we rather leave things as they are?
My personal preference would be to apply this to the uncompressed size as well. But other users' opinions and expectations are as relevant as mine. So, please speak out.
Cheers,
Stefan
> --
>
> / daniel.haxx.se || https://rock-solid.curl.dev
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
> Etiquette: https://curl.se/mail/etiquette.html
Date: Mon, 2 Mar 2026 10:13:15 +0100
> Am 02.03.2026 um 09:53 schrieb Daniel Stenberg via curl-users <curl-users_at_lists.haxx.se>:
>
> Hi team,
>
> Every once in a while someone reports the compression bomb risk with curl and --compressed as a vulnerability. We regularly dismiss that as we believe we document this risk and behavior.
>
> Still, the risk is there: if you use --compressed, a tiny download can be decompressed into a HUGE destination file.
>
> The --max-filesize option does not help here because it sets a limit to the size of the downloaded file, and one of these "bombs" does not have to be a big download.
>
> But maybe we can do better?
>
> Would it make sense to have some kind of limit to the "explosion factor" ? Should perhaps the --max-filesize limit be applied on the uncompressed size as well ? Should there be a new separate option? Or should we rather leave things as they are?
My personal preference would be to apply this to the uncompressed size as well. But other users' opinions and expectations are as relevant as mine. So, please speak out.
Cheers,
Stefan
> --
>
> / daniel.haxx.se || https://rock-solid.curl.dev
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users
> Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-users Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-03-02