Python-urllib3
Уязвимости
12
Эксплуатируемые
0
Макс. CVSS
8.9
Макс. EPSS
0.04488
Распределение по критичности
Критический
0
Высокий
3
Средний
9
Низкий
0
Также сопоставлено как (исходные строки): python-urllib3
Топ уязвимостей
CVE-2026-21441urllib3 - это HTTP-клиент-библиотека для Python. urllib3 потоковый API предназначен для эффективной обработки больших HTTP-ответов путем чтения контента в куски, а не для загрузки всего тела отклика в память сразу. urllib3 может выполнять декодирование или декомпрессию на основе заголовка HTTP `Content-Encoding`(e., `gzip`, `gzip`, `br`, `r`, `r`, `z. При использовании потокового API библиотека распаковывает только необходимые байты, что позволяет частичное потребление контента. Начиная с версии 1.22 и до версии 2.6.3, для перенаправления HTTP ответов библиотека будет считывать весь корпус ответа, чтобы истощить соединение и распаковать содержимое без необходимости. Эта декомпрессия происходила еще до того, как были вызваны какие-либо методы чтения, а сконфигурированные лимиты чтения не ограничивали количество декомпрессированных данных. В результате не было никакой защиты от декомпрессионных бомб. Вредоносный сервер может использовать это, чтобы вызвать чрезмерное потребление ресурсов на клиенте. Приложения и библиотеки затрагиваются, когда они транслируют контент из ненадежных источников, настраивая `preload_content=False` когда они не отключают перенаправления. Пользователи должны обновиться как минимум до urllib3 v2.6.3, в котором библиотека не декодирует содержимое ответов перенаправления при `preload_content=False`. Если модернизация невозможна сразу, отключите перенаправление, установив `redirect=False` запросы к ненадежному источнику.
CVE-2025-66418urllib3 - это удобная для пользователя HTTP-клиент-библиотека для Python. Начиная с версии 1.24 и до 2.6.0, количество звеньев в цепочке декомпрессии было безграничным, что позволяло вредоносному серверу вставлять практически неограниченное количество шагов сжатия, что приводит к высокому использованию процессора и массовому распределению памяти для декомпрессированных данных. Эта уязвимость фиксируется в пункте 2.6.0.
CVE-2019-11324Библиотека urllib3 до версии 1.24.2 для Python неправильно обрабатывает определенные случаи, когда желаемый набор сертификатов CA отличается от хранилища сертификатов CA в ОС, что приводит к успешному установлению SSL-соединений в ситуациях, когда правильным результатом является сбой проверки. Это связано с использованием аргумента ssl_context, ca_certs или ca_certs_dir.
CVE-2020-26137urllib3 версий до 1.25.9 допускает внедрение CRLF, если злоумышленник контролирует метод HTTP-запроса, как продемонстрировано путем вставки управляющих символов CR и LF в первый аргумент putrequest(). ПРИМЕЧАНИЕ: это похоже на CVE-2020-26116.
CVE-2019-11236В библиотеке urllib3 до версии 1.24.1 для Python возможна инъекция CRLF, если злоумышленник контролирует параметр запроса.
CVE-2025-50182urllib3 - это удобная для пользователя HTTP-клиент-библиотека для Python. Начиная с версии 2.2.0 и до 2.5.0, urllib3 не контролирует перенаправления в браузерах, а Node.js. urllib3 поддерживает использование в режиме выполнения Pyodide с использованием API JavaScript Fetch или обратно на XMLHttpRequest. Это означает, что библиотеки Python могут использоваться для выполнения HTTP-запросов от браузера или Node.js. Кроме того, urllib3 обеспечивает механизм управления перенаправлениями, но параметры повторного и перенаправления игнорируются с помощью Pyodide; само время выполнения определяет поведение перенаправления. Эта проблема была исправлена в версии 2.5.0.
CVE-2025-50181urllib3 - это удобная для пользователя HTTP-клиент-библиотека для Python. До 2.5.0 можно отключить перенаправления для всех запросов, инстанцируя Manager и указав повторные перенаправления таким образом, чтобы отключить перенаправления. По умолчанию запросы и пользователи ботокора не затрагиваются. Приложение, пытающее смягчить SSRF или открыть уязвимости перенаправления путем отключения перенаправлений на уровне PoolManager, останется уязвимым. Эта проблема была исправлена в версии 2.5.0.
CVE-2018-25091urllib3 до версии 1.24.2 не удаляет заголовок HTTP-авторизации при переходе по междоменному редиректу (т. е. редиректу, который отличается хостом, портом или схемой). Это может привести к тому, что учетные данные в заголовке авторизации будут раскрыты непреднамеренным хостам или переданы в открытом виде. ПРИМЕЧАНИЕ: эта проблема существует из-за неполного исправления CVE-2018-20060 (которое было чувствительно к регистру).
CVE-2023-43804urllib3 — это удобная библиотека HTTP-клиента для Python. urllib3 не обрабатывает HTTP-заголовок `Cookie` как специальный и не предоставляет вспомогательных средств для управления куками в HTTP, это лежит на ответственности пользователя. Тем не менее, существует возможность, что пользователь может указать заголовок `Cookie` и невольно раскрыть информацию через HTTP-перенаправления на другой источник, если этот пользователь не отключит перенаправления явно. Эта проблема была исправлена в версии urllib3 1.26.17 или 2.0.5.
CVE-2018-20060urllib3 до версии 1.23 не удаляет заголовок HTTP Authorization при переходе по межсайтовому редиректу (т. е. редиректу, который отличается хостом, портом или схемой). Это может привести к тому, что учетные данные в заголовке Authorization будут раскрыты непреднамеренным хостам или переданы в открытом виде.
CVE-2024-37891urllib3 - это удобная библиотека HTTP-клиента для Python. При использовании поддержки прокси-сервера urllib3 с `ProxyManager` заголовок `Proxy-Authorization` отправляется только настроенному прокси-серверу, как и ожидалось. Однако при отправке HTTP-запросов *без* использования поддержки прокси-сервера urllib3 можно случайно настроить заголовок `Proxy-Authorization`, даже если он не будет иметь никакого эффекта, поскольку запрос не использует прокси-сервер пересылки или туннельный прокси-сервер. В этих случаях urllib3 не рассматривает HTTP-заголовок `Proxy-Authorization` как содержащий аутентификационные данные и, таким образом, не удаляет заголовок при перенаправлениях между источниками. Поскольку это очень маловероятный сценарий, мы считаем, что серьезность этой уязвимости низка для почти всех пользователей. Из-за чрезмерной осторожности urllib3 будет автоматически удалять заголовок `Proxy-Authorization` во время перенаправлений между источниками, чтобы избежать небольшого шанса, что пользователи делают это случайно. Пользователям следует использовать поддержку прокси-сервера urllib3 или отключить автоматические перенаправления для обеспечения безопасной обработки заголовка `Proxy-Authorization`, но мы все же решили удалить заголовок по умолчанию, чтобы еще больше защитить пользователей, которые не используют правильный подход. Мы считаем, что количество использований, затронутых этим советом, невелико. Чтобы это можно было использовать, необходимо, чтобы выполнялись все следующие условия: 1. Установка заголовка `Proxy-Authorization` без использования встроенной поддержки прокси-сервера urllib3. 2. Не отключение HTTP-перенаправлений. 3. Либо не использование исходного HTTPS-сервера, либо перенаправление прокси-сервера или целевого источника на вредоносный источник. Пользователям рекомендуется обновиться до версии 1.26.19 или версии 2.2.2. Пользователи, не имеющие возможности обновиться, могут использовать заголовок `Proxy-Authorization` с помощью `ProxyManager` urllib3, отключать HTTP-перенаправления с помощью `redirects=False` при отправке запросов или не использовать заголовок `Proxy-Authorization` в качестве мер по смягчению последствий.
CVE-2023-45803urllib3 - это удобная библиотека HTTP-клиента для Python. Ранее urllib3 не удалял тело HTTP-запроса, когда ответ на HTTP-перенаправление использовал статус 301, 302 или 303 после того, как метод запроса был изменен с метода, который мог принимать тело запроса (типа `POST`), на `GET`, как это требуется по стандартам HTTP. Хотя это поведение не указано в разделе для перенаправлений, его можно вывести, собрав информацию из разных секций, и мы наблюдали это поведение в других крупных реализациях HTTP-клиентов, таких как curl и веб-браузеры. Поскольку уязвимость требует, чтобы ранее надежный сервис стал скомпрометированным, чтобы иметь влияние на конфиденциальность, мы считаем, что возможность эксплуатации этой уязвимости низка. Кроме того, многие пользователи не помещают конфиденциальные данные в тела HTTP-запросов, если это так, то эта уязвимость не может быть использована. Для того, чтобы эта уязвимость оказала влияние, обе следующие условия должны быть верными: 1. Использование urllib3 и отправка конфиденциальной информации в теле HTTP-запроса (например, данных формы или JSON) и 2. Исходный сервис скомпрометирован и начинает перенаправлять с помощью 301, 302 или 303 к вредоносному партнеру или перенаправленный сервис также становится скомпрометированным. Эта проблема была исправлена в версиях 1.26.18 и 2.0.7, и пользователям рекомендуется обновить, чтобы решить эту проблему. Пользователи, не имеющие возможности обновить, должны отключить перенаправления для сервисов, которые не ожидают ответа с перенаправлениями с помощью `redirects=False`, и отключить автоматические перенаправления с помощью `redirects=False`, а также ручным образом обрабатывать перенаправления 301, 302 и 303, удаляя тело HTTP-запроса.