anchore_overrides,nvd

Haxx

Уязвимости

188

Эксплуатируемые

Критический

Высокий

Топ продуктов

Curl152 Libcurl67 Wcurl1

Топ уязвимостей

CVE-2000-0973Переполнение буфера в curl версий ранее 6.0-1.1 и curl-ssl версий ранее 6.0-1.2 позволяет удаленным злоумышленникам выполнять произвольные команды, принудительно генерируя длинное сообщение об ошибке.

CVE-2022-32207Когда curl < 7.84.0 сохраняет cookie-файлы, alt-svc и данные hsts в локальные файлы, он делает операцию атомарной, завершая операцию переименованием из временного имени в конечное целевое имя файла. В этой операции переименования он может случайно *расширить* разрешения для целевого файла, оставив обновленный файл доступным для большего числа пользователей, чем предполагалось.

CVE-2016-9953Функция verify_certificate в lib/vtls/schannel.c в libcurl 7.30.0 - 7.51.0, при сборке для Windows CE с использованием серверной части schannel TLS, позволяет удаленным злоумышленникам получать конфиденциальную информацию, вызывать отказ в обслуживании (сбой) или, возможно, оказывать другое не указанное воздействие через имя сертификата wildcard, которое вызывает чтение за пределами выделенной памяти.

CVE-2016-4606Curl до 7.49.1 в Apple OS X до macOS Sierra до 10.12 позволяет удаленным или локальным злоумышленникам выполнять произвольный код, получать конфиденциальную информацию, вызывать условия отказа в обслуживании, обходить ограничения безопасности и выполнять несанкционированные действия. Это может помочь в других атаках.

CVE-2021-22945При отправке данных на MQTT-сервер libcurl <= 7.73.0 и 7.78.0 при определенных обстоятельствах могла ошибочно сохранить указатель на уже освобожденную область памяти и повторно использовать ее в последующем вызове для отправки данных, а также повторно освободить ее.

CVE-2005-0490Множественные переполнения буфера на основе стека в libcURL и cURL 7.12.1 и, возможно, других версиях позволяют удаленным вредоносным веб-серверам выполнять произвольный код через ответы в кодировке base64, которые превышают предполагаемую длину буфера при декодировании, что неправильно обрабатывается (1) функцией Curl_input_ntlm в http_ntlm.c во время аутентификации NTLM или (2) функциями Curl_krb_kauth и krb4_auth в krb4.c во время аутентификации Kerberos.

CVE-2019-5443Непривилегированный пользователь или программа может поместить код и файл конфигурации по известному непривилегированному пути (в C:/usr/local/), что приведет к тому, что curl <= 7.65.1 автоматически запустит код (как «движок» openssl) при вызове. Если этот curl вызывается привилегированным пользователем, он может делать все, что захочет.

CVE-2023-38545Этот недостаток вызывает переполнение буфера на основе кучи в процессе подключения к SOCKS5 прокси. Когда curl запрашивается передать имя хоста прокси SOCKS5 для разрешения адреса вместо того, чтобы это делал сам curl, максимальная длина имени хоста может составлять 255 байт. Если имя хоста обнаруживается длиннее, curl переключается на локальное разрешение имен и передает только разрешенный адрес. Из-за этой ошибки локальная переменная, означающая "позволить хосту разрешить имя", может получить неправильное значение во время медленного рукопожатия SOCKS5 и, вопреки намерению, копирует слишком длинное имя хоста в целевой буфер вместо того, чтобы копировать только разрешенный адрес. Целевой буфер является буфером на основе кучи, а имя хоста поступает из URL, с которым curl получил указание работать.

CVE-2022-27778Использование некорректно разрешенного имени, уязвимость, исправленная в 7.83.1, может привести к удалению неправильного файла, если `--no-clobber` используется вместе с `--remove-on-error`.

CVE-2022-22576В curl с 7.33.0 по 7.82.0 существует уязвимость неправильной аутентификации, которая может позволить повторно использовать соединения, аутентифицированные OAUTH2, без надлежащей проверки того, что соединение было аутентифицировано с теми же учетными данными, которые были установлены для этой передачи. Это относится к протоколам с поддержкой SASL: SMPTP(S), IMAP(S), POP3(S) и LDAP(S) (только openldap).

CVE-2021-22901curl 7.75.0 through 7.76.1 suffers from a use-after-free vulnerability resulting in already freed memory being used when a TLS 1.3 session ticket arrives over a connection. A malicious server can use this in rare unfortunate circumstances to potentially reach remote code execution in the client. When libcurl at run-time sets up support for TLS 1.3 session tickets on a connection using OpenSSL, it stores pointers to the transfer in-memory object for later retrieval when a session ticket arrives. If the connection is used by multiple transfers (like with a reused HTTP/1.1 connection or multiplexed HTTP/2 connection) that first transfer object might be freed before the new session is established on that connection and then the function will access a memory buffer that might be freed. When using that memory, libcurl might even call a function pointer in the object, making it possible for a remote code execution if the server could somehow manage to get crafted memory content into the correct place in memory.

CVE-2016-9952Функция verify_certificate в lib/vtls/schannel.c в libcurl 7.30.0 - 7.51.0, при сборке для Windows CE с использованием серверной части schannel TLS, упрощает для удаленных злоумышленников проведение атак "человек посередине" через специально созданный wildcard SAN в сертификате сервера, как продемонстрировано "*.com.".

CVE-2016-5421Уязвимость use-after-free в libcurl до версии 7.50.1 позволяет злоумышленникам контролировать, какое соединение используется, или, возможно, оказывать другое неуказанное воздействие через неизвестные векторы.

CVE-2017-9502В curl до версии 7.54.1 в Windows и DOS функция протокола libcurl по умолчанию, которая представляет собой логику, позволяющую приложению устанавливать, какой протокол libcurl должен пытаться использовать, когда задан URL-адрес без части схемы, имела недостаток, который мог привести к перезаписи буфера памяти на основе кучи семью байтами. Если протокол по умолчанию указан как FILE или URL-адрес file: не имеет двух слэшей, заданный "URL" начинается с буквы диска, и libcurl построен для Windows или DOS, то libcurl скопирует путь на 7 байтов, так что конец заданного пути будет записывать за пределы буфера malloc (7 байтов - это длина в байтах ascii-строки "file://").

CVE-2016-4802Множественные уязвимости, связанные с ненадежным путем поиска, в cURL и libcurl версий до 7.49.1, когда сборка выполнена с поддержкой SSPI или telnet, позволяют локальным пользователям выполнять произвольный код и проводить атаки с захватом DLL через троянского коня (1) security.dll, (2) secur32.dll или (3) ws2_32.dll в каталоге приложения или текущем рабочем каталоге.

CVE-2026-6276Использование либеркрла, когда пользовательский `Host:` заголовок сначала установлен для HTTP-запроса и второй запрос выполняется впоследствии с использованием той же *легкой ручки*, но без пользовательской `Host:` заголовка, второй запрос будет использовать устаревший информация и передача файлов cookie, предназначенных для первого хоста во втором запрос. Утечка их.

CVE-2026-5773libcurl может в некоторых обстоятельствах повторно использовать неправильное соединение для SMB(S) Трансферы. libcurl имеет пул последних соединений, чтобы последующие запросы могли повторно использовать существующее соединение, чтобы избежать накладных затрат. При повторном использовании соединения необходимо выполнить ряд критериев. Из-за логического ошибка в коде, операция передачи сети, которая была запрошена приложение может неправомерно повторно использовать существующее соединение SMB к тому же сервер, который использовал другой «акции», чем новый последующий перенос Должны. Это может в неудачных ситуациях привести к загрузке неправильного файла или Загрузить файл в неправильное место. Когда это происходит, те же полномочия Используются, и имя сервера одинаково.

CVE-2026-3805При повторном выполнении второго запроса SMB к тому же хосту, завиток будет неправильно использовать Указатель данных, указывающий на уже освобожденную память.

CVE-2025-9086В curl версий от 7.31.0 до 8.15.0 обнаружена уязвимость, связанная с выходом за пределы буфера при чтении пути cookie. Злоумышленник, контролирующий сайт http://target, может воспользоваться этой уязвимостью, чтобы переопределить содержимое безопасного cookie [1]. Источники: - [1] https://curl.se/docs/CVE-2025-9086.json - [2] https://curl.se/docs/CVE-2025-9086.html - [3] https://hackerone.com/reports/3294999

CVE-2025-5399Из-за ошибки в коде WebSocket libcurl, вредоносный сервер может отправить специально созданный пакет, который заставляет libcurl陷入 бесконечный цикл. Нет другого способа для приложения выйти из этого цикла, кроме как завершить поток/процесс. Это может быть использовано для DoS libcurl-использующих приложений [1]. Источники: - [1] https://curl.se/docs/CVE-2025-5399.json - [2] https://curl.se/docs/CVE-2025-5399.html - [3] https://hackerone.com/reports/3168039

CVE-2024-2398Когда приложение говорит libcurl, что хочет разрешить серверное событие HTTP/2, и количество полученных заголовков для события превышает максимально допустимый лимит (1000), libcurl прекращает серверное событие. При прекращении libcurl непреднамеренно не освобождает все ранее выделенные заголовки и, таким образом, приводит к утечке памяти. Кроме того, это состояние ошибки бесшумно завершается и, следовательно, не может быть легко обнаружено приложением.

CVE-2023-38039Когда curl извлекает HTTP-ответ, он сохраняет входящие заголовки, чтобы получить к ним доступ позже через API заголовков libcurl. Однако curl не имел ограничений на количество или размер заголовков, которые он принимал в ответе, что позволяло злонамеренному серверу передавать бесконечную серию заголовков и в конечном итоге вызывать исчерпание кучи.

CVE-2022-43551Уязвимость существует в curl <7.87.0 при проверке HSTS, которую можно обойти, чтобы заставить его продолжать использовать HTTP. Используя поддержку HSTS, curl можно настроить на использование HTTPS вместо использования небезопасного открытого HTTP-шага, даже если указывается HTTP в URL. Однако механизм HSTS может быть обойден, если имя хоста в заданном URL сначала использует символы IDN, которые заменяются на соответствующие ASCII символы в рамках преобразования IDN. Например, вместо общего ASCII точки (U+002E) `.` использовать символ UTF-8 U+3002 (ИДЕОГРАФИЧЕСКАЯ ЗАВЕРШАЮЩАЯ ТОЧКА). Затем в следующем запросе он не обнаруживает состояние HSTS и выполняет передачу открытым текстом. Поскольку он бы сохранял информацию в закодированном IDN, но искал бы её в декодированном IDN.

CVE-2022-42916В curl до версии 7.86.0 можно было обойти проверку HSTS, чтобы обманом заставить его оставаться с HTTP. Используя поддержку HSTS, curl можно инструктировать использовать HTTPS напрямую (вместо использования небезопасного шага HTTP в виде открытого текста), даже если HTTP указан в URL-адресе. Этот механизм можно было обойти, если имя хоста в данном URL-адресе использует символы IDN, которые заменяются аналогами ASCII в рамках преобразования IDN, например, с использованием символа UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) вместо общей ASCII полной остановки U+002E (.). Самая ранняя затронутая версия — 7.77.0 2021-05-26.

CVE-2022-42915curl до версии 7.86.0 имеет двойное освобождение памяти. Если curl сообщает использовать HTTP-прокси для передачи с URL-адресом, отличным от HTTP(S), он настраивает соединение с удаленным сервером, отправляя запрос CONNECT прокси, а затем туннелирует остальную часть протокола через него. HTTP-прокси может отклонить этот запрос (HTTP-прокси часто разрешают исходящие соединения только с определенными номерами портов, например, 443 для HTTPS) и вместо этого вернуть клиенту код состояния, отличный от 200. Из-за недостатков в обработке ошибок/очистки это может вызвать двойное освобождение памяти в curl, если в URL-адресе для передачи использовалась одна из следующих схем: dict, gopher, gophers, ldap, ldaps, rtmp, rtmps или telnet. Самая ранняя затронутая версия — 7.77.0.

Открыть в каталоге с фильтром по вендору →