Уязвимость функции fopen() библиотеки libcurl, связанная с ошибками управления состоянием, позволяющая нарушителю  создать или перезаписать защищенные файлы

Уязвимость интерфейса утилиты командной строки cURL, позволяющая нарушителю вызвать отказ в обслуживании

Уязвимость реализации протокола SOCKS5 утилиты командной строки cURL, позволяющая нарушителю вызвать отказ в обслуживании или выполнить произвольный код

Уязвимость функции curl_easy_duphandle библиотеки libcurl, позволяющая нарушителю создать или перезаписать файлы cookie

Rejected reason: We issued this CVE pre-maturely, as we have subsequently realized that this issue points out a problem that there really is no safe measures around or protections for.

When curl retrieves an HTTP response, it stores the incoming headers so that
they can be accessed later via the libcurl headers API.

However, curl did not have a limit in how many or how large headers it would
accept in a response, allowing a malicious server to stream an endless series
of headers and eventually cause curl to run out of heap memory.

This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy
handshake.

When curl is asked to pass along the host name to the SOCKS5 proxy to allow
that to resolve the address instead of it getting done by curl itself, the
maximum length that host name can be is 255 bytes.

If the host name is detected to be longer, curl switches to local name
resolving and instead passes on the resolved address only. Due to this bug,
the local variable that means "let the host resolve the name" could get the
wrong value during a slow SOCKS5 handshake, and contrary to the intention,
copy the too long host name to the target buffer instead of copying just the
resolved address there.

The target buffer being a heap based buffer, and the host name coming from the
URL that curl has been told to operate with.

This flaw allows an attacker to insert cookies at will into a running program
using libcurl, if the specific series of conditions are met.

libcurl performs transfers. In its API, an application creates "easy handles"
that are the individual handles for single transfers.

libcurl provides a function call that duplicates en easy handle called
[curl_easy_duphandle](https://curl.se/libcurl/c/curl_easy_duphandle.html).

If a transfer has cookies enabled when the handle is duplicated, the
cookie-enable state is also cloned - but without cloning the actual
cookies. If the source handle did not read any cookies from a specific file on
disk, the cloned version of the handle would instead store the file name as
`none` (using the four ASCII letters, no quotes).

Subsequent use of the cloned handle that does not explicitly set a source to
load cookies from would then inadvertently load cookies from a file named
`none` - if such a file exists and is readable in the current directory of the
program using libcurl. And if using the correct file format of course.