Python-urllib3
Уязвимости
20
Эксплуатируемые
0
Макс. CVSS
8.9
Макс. EPSS
0.04857
Распределение по критичности
Критический
0
Высокий
8
Средний
10
Низкий
2
Также сопоставлено как (исходные строки): python-urllib3
Топ уязвимостей
CVE-2026-44432urllib3 - это HTTP-клиент-библиотека для Python. От 2.6.0 до 2.7.0 urllib3 мог распаковать весь ответ вместо запрошенной части (1) во время второго звонка HTTPResponse.read(amt=N), когда ответ был декомпрессирован с использованием официальной библиотеки Brotli или (2), когда HTTPResponse.drain_conn() был вызван после того, как ответ был прочизна и частично декомпрессирован (агулятор сжатия не имеет значения здесь). Эти проблемы могут привести к тому, что urllib3 полностью расшифрует небольшое количество высоко сжатых данных за одну операцию. Это может привести к чрезмерному потреблению ресурсов (высокое использование процессора и массовое распределение памяти для декомпрессированных данных) на стороне клиента. Эта уязвимость фиксируется в разделе 2.7.0.
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-66471urllib3 - это удобная для пользователя HTTP-клиент-библиотека для Python. Начиная с версии 1.0 и до 2.6.0, Streaming API неправильно обрабатывает сильно сжатые данные. Потоковый API urllib3 предназначен для эффективной обработки больших ответов HTTP путем чтения контента в куски, а не для загрузки всего тела отклика в память сразу. При потоковой трансляции сжатого ответа urllib3 может выполнять декодирование или декомпрессию на основе заголовка HTTP-контент-кодирования (например, gzip, дефлейт, br или zstd). Библиотека должна читать сжатые данные из сети и распаковывать их до тех пор, пока не будет выполнен запрошенный размер куска. Любые полученные декомпрессованные данные, превышающие запрашиваемые суммы, удерживаются во внутреннем буфере для следующей операции чтения. Логика декомпрессии может привести к тому, что urllib3 полностью расшифрует небольшое количество высоко сжатых данных за одну операцию. Это может привести к чрезмерному потреблению ресурсов (высокое использование процессора и массовое распределение памяти для декомпрессированных данных.
CVE-2025-66418urllib3 - это удобная для пользователя HTTP-клиент-библиотека для Python. Начиная с версии 1.24 и до 2.6.0, количество звеньев в цепочке декомпрессии было безграничным, что позволяло вредоносному серверу вставлять практически неограниченное количество шагов сжатия, что приводит к высокому использованию процессора и массовому распределению памяти для декомпрессированных данных. Эта уязвимость фиксируется в пункте 2.6.0.
CVE-2026-44431urllib3 - это HTTP-клиент-библиотека для Python. С 1.23 до 2.7.0 перекрестные перенаправления следовали с низкоуровневого API через ProxyManager.connection_rl().urlopen(..., authentic_same_host=False), все еще перенаправляют эти чувствительные заголовки. Эта уязвимость фиксируется в разделе 2.7.0.
CVE-2021-33503В urllib3 до версии 1.26.5 обнаружена проблема. Когда предоставлен URL-адрес, содержащий множество символов @ в компоненте authority, регулярное выражение authority демонстрирует катастрофическое возвращение, вызывая отказ в обслуживании, если URL-адрес передан в качестве параметра или перенаправлен через HTTP-перенаправление.
CVE-2020-7212Функция _encode_invalid_chars в util/url.py в библиотеке urllib3 1.25.2–1.25.7 для Python допускает отказ в обслуживании (потребление ЦП) из-за неэффективного алгоритма. Массив percent_encodings содержит все совпадения кодировок в процентах. Он не дедуплицирован. Для URL-адреса длиной N размер percent_encodings может достигать O(N). Следующий шаг (нормализация существующих байтов, закодированных в процентах) также занимает до O(N) для каждого шага, поэтому общее время составляет O(N^2). Если бы percent_encodings были дедуплицированы, время вычисления _encode_invalid_chars было бы O(kN), где k не более 484 ((10+6*2)^2).
CVE-2019-11324Библиотека urllib3 до версии 1.24.2 для Python неправильно обрабатывает определенные случаи, когда желаемый набор сертификатов CA отличается от хранилища сертификатов CA в ОС, что приводит к успешному установлению SSL-соединений в ситуациях, когда правильным результатом является сбой проверки. Это связано с использованием аргумента ssl_context, ca_certs или ca_certs_dir.
CVE-2021-28363Библиотека urllib3 1.26.x до 1.26.4 для Python в некоторых случаях пропускает проверку SSL-сертификата, связанную с HTTPS к HTTPS-прокси. Первоначальное подключение к HTTPS-прокси (если SSLContext не задан через proxy_config) не проверяет имя хоста сертификата. Это означает, что сертификаты для разных серверов, которые по-прежнему правильно проверяются с помощью SSLContext urllib3 по умолчанию, будут молча приняты.
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-запроса.
CVE-2016-9015Версии 1.17 и 1.18 библиотеки Python urllib3 подвержены уязвимости, которая может привести к тому, что в определенных конфигурациях они не будут правильно проверять TLS-сертификаты. Это подвергает пользователей библиотеки с этими конфигурациями риску атак типа "человек посередине" и утечки информации. Эта уязвимость затрагивает пользователей, использующих версии 1.17 и 1.18 библиотеки urllib3, которые используют дополнительную поддержку PyOpenSSL для TLS вместо обычного стандартного TLS-бэкенда библиотеки, и которые используют OpenSSL 1.1.0 через PyOpenSSL. Это крайне редкая конфигурация, поэтому влияние этой уязвимости на безопасность невелико.
CVE-2013-2099Уязвимость, связанная со сложностью алгоритма, в функции ssl.match_hostname в Python 3.2.x, 3.3.x и более ранних версиях, а также в неуказанных версиях python-backports-ssl_match_hostname, используемых для более старых версий Python, позволяет удаленным злоумышленникам вызывать отказ в обслуживании (потребление ЦП) через несколько подстановочных знаков в общем имени в сертификате.