Safety CI > kgarun/myratings

pyup-scheduled-update-2020-12-01

5 years, 6 months ago

Update click from 7.0 to 7.1.2

cryptography 2.3.1, lxml 4.2.5 and 4 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230719.txt
cryptography	2.3.1	<42.0.2	show The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<42.0.0	show Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.
cryptography	2.3.1	<41.0.4	show Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix. https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512
cryptography	2.3.1	<42.0.5	show Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks. https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<=3.2	show Cryptography 3.2 and prior are vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
cryptography	2.3.1	<3.3.2	show Cryptography 3.3.2 includes a fix for CVE-2020-36242: certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class.
cryptography	2.3.1	<3.3	show Cryptography 3.3 no longer allows loading of finite field Diffie-Hellman parameters of less than 512 bits in length. This change is to conform with an upcoming OpenSSL release that no longer supports smaller sizes. These keys were already wildly insecure and should not have been used in any application outside of testing. https://github.com/pyca/cryptography/pull/5592
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl. https://github.com/pyca/cryptography/issues/7940
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d https://www.openssl.org/news/secadv/20230731.txt
cryptography	2.3.1	<42.0.0	show Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
cryptography	2.3.1	<46.0.5	show Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.
cryptography	2.3.1	<41.0.5	show Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.
cryptography	2.3.1	<42.0.8	show The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230714.txt
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=1.8,<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.
cryptography	2.3.1	<46.0.6	show Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.
cryptography	2.3.1	<41.0.0	show Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix. https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<41.0.2	show The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.
lxml	4.2.5	<6.1.0	show Affected versions of the lxml package are vulnerable to XML External Entity Injection due to insecure default parser configuration that resolves external entities. The iterparse() function and the ETCompatXMLParser() class both default to resolve_entities=True, so untrusted XML input processed through either parser will expand external entity references and read referenced local files from the host. An attacker who supplies a crafted XML document to an application using these parsers in their default configuration can read sensitive local files and exfiltrate their contents through the parsed output.
lxml	4.2.5	<4.9.1	show Lxml 4.9.1 includes a fix for CVE-2022-2309: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.
lxml	4.2.5	<4.6.3	show Lxml version 4.6.3 includes a fix for CVE-2021-28957: An XSS vulnerability was discovered in python-lxml's clean module versions before 4.6.3. When disabling the safe_attrs_only and forms arguments, the Cleaner class does not remove the formation attribute allowing for JS to bypass the sanitizer. A remote attacker could exploit this flaw to run arbitrary JS code on users who interact with incorrectly sanitized HTML. https://bugs.launchpad.net/lxml/+bug/1888153
lxml	4.2.5	<4.6.2	show Lxml 4.6.2 includes a fix for CVE-2020-27783: A XSS vulnerability was discovered in python-lxml's clean module. The module's parser didn't properly imitate browsers, which caused different behaviors between the sanitizer and the user's page. A remote attacker could exploit this flaw to run arbitrary HTML/JS code.
lxml	4.2.5	<4.6.5	show Lxml 4.6.5 includes a fix for CVE-2021-43818: Prior to version 4.6.5, the HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs. Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5 to receive a patch.
lxml	4.2.5	<4.4.0	show In lxml before 4.4.0, when writing to file paths that contain the URL escape character '%', the file path could wrongly be mangled by URL unescaping and thus write to a different file or directory. Code that writes to file paths that are provided by untrusted sources, but that must work with previous versions of lxml, should best either reject paths that contain '%' characters, or otherwise make sure that the path does not contain maliciously injected '%XX' URL hex escapes for paths like '../'. https://github.com/lxml/lxml/commit/0245aba002f069a0b157282707bdf77418d1b5be
PyYAML	3.13	<4	show Pyyaml before 4 uses ``yaml.load`` which has been assigned CVE-2017-18342.
PyYAML	3.13	<5.3.1	show Pyyaml 5.3.1 includes a fix for CVE-2020-1747: A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. An attacker could use this flaw to execute arbitrary code on the system by abusing the python/object/new constructor.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-12-01

5 years, 6 months ago

8a98647d

Update cffi from 1.11.5 to 1.14.4

cryptography 2.3.1, lxml 4.2.5 and 4 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230719.txt
cryptography	2.3.1	<42.0.2	show The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<42.0.0	show Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.
cryptography	2.3.1	<41.0.4	show Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix. https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512
cryptography	2.3.1	<42.0.5	show Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks. https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<=3.2	show Cryptography 3.2 and prior are vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
cryptography	2.3.1	<3.3.2	show Cryptography 3.3.2 includes a fix for CVE-2020-36242: certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class.
cryptography	2.3.1	<3.3	show Cryptography 3.3 no longer allows loading of finite field Diffie-Hellman parameters of less than 512 bits in length. This change is to conform with an upcoming OpenSSL release that no longer supports smaller sizes. These keys were already wildly insecure and should not have been used in any application outside of testing. https://github.com/pyca/cryptography/pull/5592
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl. https://github.com/pyca/cryptography/issues/7940
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d https://www.openssl.org/news/secadv/20230731.txt
cryptography	2.3.1	<42.0.0	show Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
cryptography	2.3.1	<46.0.5	show Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.
cryptography	2.3.1	<41.0.5	show Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.
cryptography	2.3.1	<42.0.8	show The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230714.txt
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=1.8,<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.
cryptography	2.3.1	<46.0.6	show Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.
cryptography	2.3.1	<41.0.0	show Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix. https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<41.0.2	show The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.
lxml	4.2.5	<6.1.0	show Affected versions of the lxml package are vulnerable to XML External Entity Injection due to insecure default parser configuration that resolves external entities. The iterparse() function and the ETCompatXMLParser() class both default to resolve_entities=True, so untrusted XML input processed through either parser will expand external entity references and read referenced local files from the host. An attacker who supplies a crafted XML document to an application using these parsers in their default configuration can read sensitive local files and exfiltrate their contents through the parsed output.
lxml	4.2.5	<4.9.1	show Lxml 4.9.1 includes a fix for CVE-2022-2309: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.
lxml	4.2.5	<4.6.3	show Lxml version 4.6.3 includes a fix for CVE-2021-28957: An XSS vulnerability was discovered in python-lxml's clean module versions before 4.6.3. When disabling the safe_attrs_only and forms arguments, the Cleaner class does not remove the formation attribute allowing for JS to bypass the sanitizer. A remote attacker could exploit this flaw to run arbitrary JS code on users who interact with incorrectly sanitized HTML. https://bugs.launchpad.net/lxml/+bug/1888153
lxml	4.2.5	<4.6.2	show Lxml 4.6.2 includes a fix for CVE-2020-27783: A XSS vulnerability was discovered in python-lxml's clean module. The module's parser didn't properly imitate browsers, which caused different behaviors between the sanitizer and the user's page. A remote attacker could exploit this flaw to run arbitrary HTML/JS code.
lxml	4.2.5	<4.6.5	show Lxml 4.6.5 includes a fix for CVE-2021-43818: Prior to version 4.6.5, the HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs. Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5 to receive a patch.
lxml	4.2.5	<4.4.0	show In lxml before 4.4.0, when writing to file paths that contain the URL escape character '%', the file path could wrongly be mangled by URL unescaping and thus write to a different file or directory. Code that writes to file paths that are provided by untrusted sources, but that must work with previous versions of lxml, should best either reject paths that contain '%' characters, or otherwise make sure that the path does not contain maliciously injected '%XX' URL hex escapes for paths like '../'. https://github.com/lxml/lxml/commit/0245aba002f069a0b157282707bdf77418d1b5be
PyYAML	3.13	<4	show Pyyaml before 4 uses ``yaml.load`` which has been assigned CVE-2017-18342.
PyYAML	3.13	<5.3.1	show Pyyaml 5.3.1 includes a fix for CVE-2020-1747: A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. An attacker could use this flaw to execute arbitrary code on the system by abusing the python/object/new constructor.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-12-01

5 years, 6 months ago

7b4d3415

Update certifi from 2018.10.15 to 2020.11.8

cryptography 2.3.1, lxml 4.2.5 and 4 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230719.txt
cryptography	2.3.1	<42.0.2	show The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<42.0.0	show Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.
cryptography	2.3.1	<41.0.4	show Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix. https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512
cryptography	2.3.1	<42.0.5	show Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks. https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<=3.2	show Cryptography 3.2 and prior are vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
cryptography	2.3.1	<3.3.2	show Cryptography 3.3.2 includes a fix for CVE-2020-36242: certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class.
cryptography	2.3.1	<3.3	show Cryptography 3.3 no longer allows loading of finite field Diffie-Hellman parameters of less than 512 bits in length. This change is to conform with an upcoming OpenSSL release that no longer supports smaller sizes. These keys were already wildly insecure and should not have been used in any application outside of testing. https://github.com/pyca/cryptography/pull/5592
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl. https://github.com/pyca/cryptography/issues/7940
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d https://www.openssl.org/news/secadv/20230731.txt
cryptography	2.3.1	<42.0.0	show Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
cryptography	2.3.1	<46.0.5	show Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.
cryptography	2.3.1	<41.0.5	show Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.
cryptography	2.3.1	<42.0.8	show The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230714.txt
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=1.8,<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.
cryptography	2.3.1	<46.0.6	show Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.
cryptography	2.3.1	<41.0.0	show Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix. https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<41.0.2	show The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.
lxml	4.2.5	<6.1.0	show Affected versions of the lxml package are vulnerable to XML External Entity Injection due to insecure default parser configuration that resolves external entities. The iterparse() function and the ETCompatXMLParser() class both default to resolve_entities=True, so untrusted XML input processed through either parser will expand external entity references and read referenced local files from the host. An attacker who supplies a crafted XML document to an application using these parsers in their default configuration can read sensitive local files and exfiltrate their contents through the parsed output.
lxml	4.2.5	<4.9.1	show Lxml 4.9.1 includes a fix for CVE-2022-2309: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.
lxml	4.2.5	<4.6.3	show Lxml version 4.6.3 includes a fix for CVE-2021-28957: An XSS vulnerability was discovered in python-lxml's clean module versions before 4.6.3. When disabling the safe_attrs_only and forms arguments, the Cleaner class does not remove the formation attribute allowing for JS to bypass the sanitizer. A remote attacker could exploit this flaw to run arbitrary JS code on users who interact with incorrectly sanitized HTML. https://bugs.launchpad.net/lxml/+bug/1888153
lxml	4.2.5	<4.6.2	show Lxml 4.6.2 includes a fix for CVE-2020-27783: A XSS vulnerability was discovered in python-lxml's clean module. The module's parser didn't properly imitate browsers, which caused different behaviors between the sanitizer and the user's page. A remote attacker could exploit this flaw to run arbitrary HTML/JS code.
lxml	4.2.5	<4.6.5	show Lxml 4.6.5 includes a fix for CVE-2021-43818: Prior to version 4.6.5, the HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs. Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5 to receive a patch.
lxml	4.2.5	<4.4.0	show In lxml before 4.4.0, when writing to file paths that contain the URL escape character '%', the file path could wrongly be mangled by URL unescaping and thus write to a different file or directory. Code that writes to file paths that are provided by untrusted sources, but that must work with previous versions of lxml, should best either reject paths that contain '%' characters, or otherwise make sure that the path does not contain maliciously injected '%XX' URL hex escapes for paths like '../'. https://github.com/lxml/lxml/commit/0245aba002f069a0b157282707bdf77418d1b5be
PyYAML	3.13	<4	show Pyyaml before 4 uses ``yaml.load`` which has been assigned CVE-2017-18342.
PyYAML	3.13	<5.3.1	show Pyyaml 5.3.1 includes a fix for CVE-2020-1747: A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. An attacker could use this flaw to execute arbitrary code on the system by abusing the python/object/new constructor.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-12-01

5 years, 6 months ago

0cefef53

Update bumpversion from 0.5.3 to 0.6.0

cryptography 2.3.1, lxml 4.2.5 and 4 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230719.txt
cryptography	2.3.1	<42.0.2	show The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<42.0.0	show Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.
cryptography	2.3.1	<41.0.4	show Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix. https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512
cryptography	2.3.1	<42.0.5	show Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks. https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<=3.2	show Cryptography 3.2 and prior are vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
cryptography	2.3.1	<3.3.2	show Cryptography 3.3.2 includes a fix for CVE-2020-36242: certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class.
cryptography	2.3.1	<3.3	show Cryptography 3.3 no longer allows loading of finite field Diffie-Hellman parameters of less than 512 bits in length. This change is to conform with an upcoming OpenSSL release that no longer supports smaller sizes. These keys were already wildly insecure and should not have been used in any application outside of testing. https://github.com/pyca/cryptography/pull/5592
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl. https://github.com/pyca/cryptography/issues/7940
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d https://www.openssl.org/news/secadv/20230731.txt
cryptography	2.3.1	<42.0.0	show Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
cryptography	2.3.1	<46.0.5	show Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.
cryptography	2.3.1	<41.0.5	show Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.
cryptography	2.3.1	<42.0.8	show The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230714.txt
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=1.8,<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.
cryptography	2.3.1	<46.0.6	show Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.
cryptography	2.3.1	<41.0.0	show Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix. https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<41.0.2	show The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.
lxml	4.2.5	<6.1.0	show Affected versions of the lxml package are vulnerable to XML External Entity Injection due to insecure default parser configuration that resolves external entities. The iterparse() function and the ETCompatXMLParser() class both default to resolve_entities=True, so untrusted XML input processed through either parser will expand external entity references and read referenced local files from the host. An attacker who supplies a crafted XML document to an application using these parsers in their default configuration can read sensitive local files and exfiltrate their contents through the parsed output.
lxml	4.2.5	<4.9.1	show Lxml 4.9.1 includes a fix for CVE-2022-2309: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.
lxml	4.2.5	<4.6.3	show Lxml version 4.6.3 includes a fix for CVE-2021-28957: An XSS vulnerability was discovered in python-lxml's clean module versions before 4.6.3. When disabling the safe_attrs_only and forms arguments, the Cleaner class does not remove the formation attribute allowing for JS to bypass the sanitizer. A remote attacker could exploit this flaw to run arbitrary JS code on users who interact with incorrectly sanitized HTML. https://bugs.launchpad.net/lxml/+bug/1888153
lxml	4.2.5	<4.6.2	show Lxml 4.6.2 includes a fix for CVE-2020-27783: A XSS vulnerability was discovered in python-lxml's clean module. The module's parser didn't properly imitate browsers, which caused different behaviors between the sanitizer and the user's page. A remote attacker could exploit this flaw to run arbitrary HTML/JS code.
lxml	4.2.5	<4.6.5	show Lxml 4.6.5 includes a fix for CVE-2021-43818: Prior to version 4.6.5, the HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs. Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5 to receive a patch.
lxml	4.2.5	<4.4.0	show In lxml before 4.4.0, when writing to file paths that contain the URL escape character '%', the file path could wrongly be mangled by URL unescaping and thus write to a different file or directory. Code that writes to file paths that are provided by untrusted sources, but that must work with previous versions of lxml, should best either reject paths that contain '%' characters, or otherwise make sure that the path does not contain maliciously injected '%XX' URL hex escapes for paths like '../'. https://github.com/lxml/lxml/commit/0245aba002f069a0b157282707bdf77418d1b5be
PyYAML	3.13	<4	show Pyyaml before 4 uses ``yaml.load`` which has been assigned CVE-2017-18342.
PyYAML	3.13	<5.3.1	show Pyyaml 5.3.1 includes a fix for CVE-2020-1747: A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. An attacker could use this flaw to execute arbitrary code on the system by abusing the python/object/new constructor.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-12-01

5 years, 6 months ago

efa5eb38

Update beautifulsoup4 from 4.6.3 to 4.9.3

cryptography 2.3.1, lxml 4.2.5 and 4 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230719.txt
cryptography	2.3.1	<42.0.2	show The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<42.0.0	show Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.
cryptography	2.3.1	<41.0.4	show Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix. https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512
cryptography	2.3.1	<42.0.5	show Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks. https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<=3.2	show Cryptography 3.2 and prior are vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
cryptography	2.3.1	<3.3.2	show Cryptography 3.3.2 includes a fix for CVE-2020-36242: certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class.
cryptography	2.3.1	<3.3	show Cryptography 3.3 no longer allows loading of finite field Diffie-Hellman parameters of less than 512 bits in length. This change is to conform with an upcoming OpenSSL release that no longer supports smaller sizes. These keys were already wildly insecure and should not have been used in any application outside of testing. https://github.com/pyca/cryptography/pull/5592
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl. https://github.com/pyca/cryptography/issues/7940
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d https://www.openssl.org/news/secadv/20230731.txt
cryptography	2.3.1	<42.0.0	show Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
cryptography	2.3.1	<46.0.5	show Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.
cryptography	2.3.1	<41.0.5	show Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.
cryptography	2.3.1	<42.0.8	show The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230714.txt
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=1.8,<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.
cryptography	2.3.1	<46.0.6	show Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.
cryptography	2.3.1	<41.0.0	show Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix. https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<41.0.2	show The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.
lxml	4.2.5	<6.1.0	show Affected versions of the lxml package are vulnerable to XML External Entity Injection due to insecure default parser configuration that resolves external entities. The iterparse() function and the ETCompatXMLParser() class both default to resolve_entities=True, so untrusted XML input processed through either parser will expand external entity references and read referenced local files from the host. An attacker who supplies a crafted XML document to an application using these parsers in their default configuration can read sensitive local files and exfiltrate their contents through the parsed output.
lxml	4.2.5	<4.9.1	show Lxml 4.9.1 includes a fix for CVE-2022-2309: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.
lxml	4.2.5	<4.6.3	show Lxml version 4.6.3 includes a fix for CVE-2021-28957: An XSS vulnerability was discovered in python-lxml's clean module versions before 4.6.3. When disabling the safe_attrs_only and forms arguments, the Cleaner class does not remove the formation attribute allowing for JS to bypass the sanitizer. A remote attacker could exploit this flaw to run arbitrary JS code on users who interact with incorrectly sanitized HTML. https://bugs.launchpad.net/lxml/+bug/1888153
lxml	4.2.5	<4.6.2	show Lxml 4.6.2 includes a fix for CVE-2020-27783: A XSS vulnerability was discovered in python-lxml's clean module. The module's parser didn't properly imitate browsers, which caused different behaviors between the sanitizer and the user's page. A remote attacker could exploit this flaw to run arbitrary HTML/JS code.
lxml	4.2.5	<4.6.5	show Lxml 4.6.5 includes a fix for CVE-2021-43818: Prior to version 4.6.5, the HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs. Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5 to receive a patch.
lxml	4.2.5	<4.4.0	show In lxml before 4.4.0, when writing to file paths that contain the URL escape character '%', the file path could wrongly be mangled by URL unescaping and thus write to a different file or directory. Code that writes to file paths that are provided by untrusted sources, but that must work with previous versions of lxml, should best either reject paths that contain '%' characters, or otherwise make sure that the path does not contain maliciously injected '%XX' URL hex escapes for paths like '../'. https://github.com/lxml/lxml/commit/0245aba002f069a0b157282707bdf77418d1b5be
PyYAML	3.13	<4	show Pyyaml before 4 uses ``yaml.load`` which has been assigned CVE-2017-18342.
PyYAML	3.13	<5.3.1	show Pyyaml 5.3.1 includes a fix for CVE-2020-1747: A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. An attacker could use this flaw to execute arbitrary code on the system by abusing the python/object/new constructor.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-12-01

5 years, 6 months ago

9ef660f8

Update babel from 2.6.0 to 2.9.0

cryptography 2.3.1, lxml 4.2.5 and 4 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230719.txt
cryptography	2.3.1	<42.0.2	show The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<42.0.0	show Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.
cryptography	2.3.1	<41.0.4	show Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix. https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512
cryptography	2.3.1	<42.0.5	show Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks. https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<=3.2	show Cryptography 3.2 and prior are vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
cryptography	2.3.1	<3.3.2	show Cryptography 3.3.2 includes a fix for CVE-2020-36242: certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class.
cryptography	2.3.1	<3.3	show Cryptography 3.3 no longer allows loading of finite field Diffie-Hellman parameters of less than 512 bits in length. This change is to conform with an upcoming OpenSSL release that no longer supports smaller sizes. These keys were already wildly insecure and should not have been used in any application outside of testing. https://github.com/pyca/cryptography/pull/5592
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl. https://github.com/pyca/cryptography/issues/7940
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d https://www.openssl.org/news/secadv/20230731.txt
cryptography	2.3.1	<42.0.0	show Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
cryptography	2.3.1	<46.0.5	show Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.
cryptography	2.3.1	<41.0.5	show Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.
cryptography	2.3.1	<42.0.8	show The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230714.txt
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=1.8,<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.
cryptography	2.3.1	<46.0.6	show Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.
cryptography	2.3.1	<41.0.0	show Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix. https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<41.0.2	show The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.
lxml	4.2.5	<6.1.0	show Affected versions of the lxml package are vulnerable to XML External Entity Injection due to insecure default parser configuration that resolves external entities. The iterparse() function and the ETCompatXMLParser() class both default to resolve_entities=True, so untrusted XML input processed through either parser will expand external entity references and read referenced local files from the host. An attacker who supplies a crafted XML document to an application using these parsers in their default configuration can read sensitive local files and exfiltrate their contents through the parsed output.
lxml	4.2.5	<4.9.1	show Lxml 4.9.1 includes a fix for CVE-2022-2309: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.
lxml	4.2.5	<4.6.3	show Lxml version 4.6.3 includes a fix for CVE-2021-28957: An XSS vulnerability was discovered in python-lxml's clean module versions before 4.6.3. When disabling the safe_attrs_only and forms arguments, the Cleaner class does not remove the formation attribute allowing for JS to bypass the sanitizer. A remote attacker could exploit this flaw to run arbitrary JS code on users who interact with incorrectly sanitized HTML. https://bugs.launchpad.net/lxml/+bug/1888153
lxml	4.2.5	<4.6.2	show Lxml 4.6.2 includes a fix for CVE-2020-27783: A XSS vulnerability was discovered in python-lxml's clean module. The module's parser didn't properly imitate browsers, which caused different behaviors between the sanitizer and the user's page. A remote attacker could exploit this flaw to run arbitrary HTML/JS code.
lxml	4.2.5	<4.6.5	show Lxml 4.6.5 includes a fix for CVE-2021-43818: Prior to version 4.6.5, the HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs. Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5 to receive a patch.
lxml	4.2.5	<4.4.0	show In lxml before 4.4.0, when writing to file paths that contain the URL escape character '%', the file path could wrongly be mangled by URL unescaping and thus write to a different file or directory. Code that writes to file paths that are provided by untrusted sources, but that must work with previous versions of lxml, should best either reject paths that contain '%' characters, or otherwise make sure that the path does not contain maliciously injected '%XX' URL hex escapes for paths like '../'. https://github.com/lxml/lxml/commit/0245aba002f069a0b157282707bdf77418d1b5be
PyYAML	3.13	<4	show Pyyaml before 4 uses ``yaml.load`` which has been assigned CVE-2017-18342.
PyYAML	3.13	<5.3.1	show Pyyaml 5.3.1 includes a fix for CVE-2020-1747: A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. An attacker could use this flaw to execute arbitrary code on the system by abusing the python/object/new constructor.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-12-01

5 years, 6 months ago

44c2d43e

Update asn1crypto from 0.24.0 to 1.4.0

cryptography 2.3.1, lxml 4.2.5 and 4 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230719.txt
cryptography	2.3.1	<42.0.2	show The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<42.0.0	show Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.
cryptography	2.3.1	<41.0.4	show Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix. https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512
cryptography	2.3.1	<42.0.5	show Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks. https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<=3.2	show Cryptography 3.2 and prior are vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
cryptography	2.3.1	<3.3.2	show Cryptography 3.3.2 includes a fix for CVE-2020-36242: certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class.
cryptography	2.3.1	<3.3	show Cryptography 3.3 no longer allows loading of finite field Diffie-Hellman parameters of less than 512 bits in length. This change is to conform with an upcoming OpenSSL release that no longer supports smaller sizes. These keys were already wildly insecure and should not have been used in any application outside of testing. https://github.com/pyca/cryptography/pull/5592
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl. https://github.com/pyca/cryptography/issues/7940
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d https://www.openssl.org/news/secadv/20230731.txt
cryptography	2.3.1	<42.0.0	show Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
cryptography	2.3.1	<46.0.5	show Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.
cryptography	2.3.1	<41.0.5	show Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.
cryptography	2.3.1	<42.0.8	show The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230714.txt
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=1.8,<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.
cryptography	2.3.1	<46.0.6	show Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.
cryptography	2.3.1	<41.0.0	show Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix. https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<41.0.2	show The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.
lxml	4.2.5	<6.1.0	show Affected versions of the lxml package are vulnerable to XML External Entity Injection due to insecure default parser configuration that resolves external entities. The iterparse() function and the ETCompatXMLParser() class both default to resolve_entities=True, so untrusted XML input processed through either parser will expand external entity references and read referenced local files from the host. An attacker who supplies a crafted XML document to an application using these parsers in their default configuration can read sensitive local files and exfiltrate their contents through the parsed output.
lxml	4.2.5	<4.9.1	show Lxml 4.9.1 includes a fix for CVE-2022-2309: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.
lxml	4.2.5	<4.6.3	show Lxml version 4.6.3 includes a fix for CVE-2021-28957: An XSS vulnerability was discovered in python-lxml's clean module versions before 4.6.3. When disabling the safe_attrs_only and forms arguments, the Cleaner class does not remove the formation attribute allowing for JS to bypass the sanitizer. A remote attacker could exploit this flaw to run arbitrary JS code on users who interact with incorrectly sanitized HTML. https://bugs.launchpad.net/lxml/+bug/1888153
lxml	4.2.5	<4.6.2	show Lxml 4.6.2 includes a fix for CVE-2020-27783: A XSS vulnerability was discovered in python-lxml's clean module. The module's parser didn't properly imitate browsers, which caused different behaviors between the sanitizer and the user's page. A remote attacker could exploit this flaw to run arbitrary HTML/JS code.
lxml	4.2.5	<4.6.5	show Lxml 4.6.5 includes a fix for CVE-2021-43818: Prior to version 4.6.5, the HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs. Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5 to receive a patch.
lxml	4.2.5	<4.4.0	show In lxml before 4.4.0, when writing to file paths that contain the URL escape character '%', the file path could wrongly be mangled by URL unescaping and thus write to a different file or directory. Code that writes to file paths that are provided by untrusted sources, but that must work with previous versions of lxml, should best either reject paths that contain '%' characters, or otherwise make sure that the path does not contain maliciously injected '%XX' URL hex escapes for paths like '../'. https://github.com/lxml/lxml/commit/0245aba002f069a0b157282707bdf77418d1b5be
PyYAML	3.13	<4	show Pyyaml before 4 uses ``yaml.load`` which has been assigned CVE-2017-18342.
PyYAML	3.13	<5.3.1	show Pyyaml 5.3.1 includes a fix for CVE-2020-1747: A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. An attacker could use this flaw to execute arbitrary code on the system by abusing the python/object/new constructor.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-12-01

5 years, 6 months ago

cfc7aa2e

Update arrow from 0.12.1 to 0.17.0

cryptography 2.3.1, lxml 4.2.5 and 4 other dependencies have known security vulnerabilities.

Package	Installed	Affected	Info
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230719.txt
cryptography	2.3.1	<42.0.2	show The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<42.0.0	show Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.
cryptography	2.3.1	<41.0.4	show Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix. https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512
cryptography	2.3.1	<42.0.5	show Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks. https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<=3.2	show Cryptography 3.2 and prior are vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.
cryptography	2.3.1	<3.3.2	show Cryptography 3.3.2 includes a fix for CVE-2020-36242: certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class.
cryptography	2.3.1	<3.3	show Cryptography 3.3 no longer allows loading of finite field Diffie-Hellman parameters of less than 512 bits in length. This change is to conform with an upcoming OpenSSL release that no longer supports smaller sizes. These keys were already wildly insecure and should not have been used in any application outside of testing. https://github.com/pyca/cryptography/pull/5592
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl. https://github.com/pyca/cryptography/issues/7940
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability. https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d https://www.openssl.org/news/secadv/20230731.txt
cryptography	2.3.1	<42.0.0	show Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.
cryptography	2.3.1	<46.0.5	show Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.
cryptography	2.3.1	<41.0.5	show Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.
cryptography	2.3.1	<42.0.8	show The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.
cryptography	2.3.1	>=0.8,<41.0.3	show Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries. https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2 https://www.openssl.org/news/secadv/20230714.txt
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	>=1.8,<39.0.1	show Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.
cryptography	2.3.1	<46.0.6	show Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.
cryptography	2.3.1	<41.0.0	show Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix. https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22
cryptography	2.3.1	<39.0.1	show Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes. https://github.com/pyca/cryptography/issues/8229
cryptography	2.3.1	<41.0.2	show The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.
lxml	4.2.5	<6.1.0	show Affected versions of the lxml package are vulnerable to XML External Entity Injection due to insecure default parser configuration that resolves external entities. The iterparse() function and the ETCompatXMLParser() class both default to resolve_entities=True, so untrusted XML input processed through either parser will expand external entity references and read referenced local files from the host. An attacker who supplies a crafted XML document to an application using these parsers in their default configuration can read sensitive local files and exfiltrate their contents through the parsed output.
lxml	4.2.5	<4.9.1	show Lxml 4.9.1 includes a fix for CVE-2022-2309: NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn't be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.
lxml	4.2.5	<4.6.3	show Lxml version 4.6.3 includes a fix for CVE-2021-28957: An XSS vulnerability was discovered in python-lxml's clean module versions before 4.6.3. When disabling the safe_attrs_only and forms arguments, the Cleaner class does not remove the formation attribute allowing for JS to bypass the sanitizer. A remote attacker could exploit this flaw to run arbitrary JS code on users who interact with incorrectly sanitized HTML. https://bugs.launchpad.net/lxml/+bug/1888153
lxml	4.2.5	<4.6.2	show Lxml 4.6.2 includes a fix for CVE-2020-27783: A XSS vulnerability was discovered in python-lxml's clean module. The module's parser didn't properly imitate browsers, which caused different behaviors between the sanitizer and the user's page. A remote attacker could exploit this flaw to run arbitrary HTML/JS code.
lxml	4.2.5	<4.6.5	show Lxml 4.6.5 includes a fix for CVE-2021-43818: Prior to version 4.6.5, the HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs. Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5 to receive a patch.
lxml	4.2.5	<4.4.0	show In lxml before 4.4.0, when writing to file paths that contain the URL escape character '%', the file path could wrongly be mangled by URL unescaping and thus write to a different file or directory. Code that writes to file paths that are provided by untrusted sources, but that must work with previous versions of lxml, should best either reject paths that contain '%' characters, or otherwise make sure that the path does not contain maliciously injected '%XX' URL hex escapes for paths like '../'. https://github.com/lxml/lxml/commit/0245aba002f069a0b157282707bdf77418d1b5be
PyYAML	3.13	<4	show Pyyaml before 4 uses ``yaml.load`` which has been assigned CVE-2017-18342.
PyYAML	3.13	<5.3.1	show Pyyaml 5.3.1 includes a fix for CVE-2020-1747: A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. An attacker could use this flaw to execute arbitrary code on the system by abusing the python/object/new constructor.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-11-01

5 years, 7 months ago

aa1d5e01

Update sphinxcontrib-websupport from 1.1.0 to 1.2.4

twine 1.12.1 and urllib3 1.24 have known security vulnerabilities.

Package	Installed	Affected	Info
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-11-01

5 years, 7 months ago

9e549850

Update sphinx from 1.8.1 to 3.2.1

twine 1.12.1 and urllib3 1.24 have known security vulnerabilities.

Package	Installed	Affected	Info
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-11-01

5 years, 7 months ago

ed582941

Update snowballstemmer from 1.2.1 to 2.0.0

Sphinx 1.8.1, twine 1.12.1 and urllib3 1.24 have known security vulnerabilities.

Package	Installed	Affected	Info
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-11-01

5 years, 7 months ago

45bef613

Update six from 1.11.0 to 1.15.0

Sphinx 1.8.1, twine 1.12.1 and urllib3 1.24 have known security vulnerabilities.

Package	Installed	Affected	Info
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-11-01

5 years, 7 months ago

7fdf98c0

Update requests-toolbelt from 0.8.0 to 0.9.1

Sphinx 1.8.1, twine 1.12.1 and urllib3 1.24 have known security vulnerabilities.

Package	Installed	Affected	Info
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-11-01

5 years, 7 months ago

911c64a3

Update requests from 2.20.0 to 2.24.0

Sphinx 1.8.1, twine 1.12.1 and urllib3 1.24 have known security vulnerabilities.

Package	Installed	Affected	Info
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

pyup-scheduled-update-2020-11-01

5 years, 7 months ago

a62eb4cc

Update pyyaml from 3.13 to 5.3.1

Sphinx 1.8.1, twine 1.12.1 and urllib3 1.24 have known security vulnerabilities.

Package	Installed	Affected	Info
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.0.4	show Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in inventory. https://github.com/sphinx-doc/sphinx/issues/8175 https://github.com/sphinx-doc/sphinx/commit/f7b872e673f9b359a61fd287a7338a28077840d2
Sphinx	1.8.1	<3.3.0	show Sphinx 3.3.0 includes a fix for a ReDoS vulnerability in docstring. https://github.com/sphinx-doc/sphinx/issues/8172 https://github.com/sphinx-doc/sphinx/commit/f00e75278c5999f40b214d8934357fbf0e705417
twine	1.12.1	<2.0.0	show Twine 2.0.0 updates requests to 2.20 (or later) to include a security fix.
urllib3	1.24	<=1.26.18 , >=2.0.0a1,<=2.2.1	show Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.
urllib3	1.24	>=1.23,<2.7.0	show Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.
urllib3	1.24	<1.25.9	show Urllib3 1.25.9 includes a fix for CVE-2020-26137: Urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this is similar to CVE-2020-26116. https://github.com/python/cpython/issues/83784 https://github.com/urllib3/urllib3/pull/1800
urllib3	1.24	<2.5.0	show urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3	1.24	<1.26.18 , >=2.0.0a1,<2.0.7	show Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False. This vulnerability is specific to Python's urllib3 library.
urllib3	1.24	<1.24.3	show Urllib3 1.24.3 includes a fix for CVE-2019-11236: CRLF injection is possible if the attacker controls the request parameter. https://github.com/urllib3/urllib3/commit/5d523706c7b03f947dc50a7e783758a2bfff0532 https://github.com/urllib3/urllib3/issues/1553
urllib3	1.24	<1.24.2	show Affected versions of urllib3 affected versions are vulnerable due to an issue where the authorization HTTP header is not removed when following a cross-origin redirect. This can result in credentials within the authorization header being exposed to unintended hosts or transmitted in cleartext. This vulnerability exists because of an incomplete fix for CVE-2018-20060, which addressed a similar issue case-sensitively.
urllib3	1.24	<1.26.17 , >=2.0.0a1,<2.0.5	show Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly. https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f
urllib3	1.24	>=1.0,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.
urllib3	1.24	>=1.22,<2.6.3	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.
urllib3	1.24	>=1.24,<2.6.0	show Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.
urllib3	1.24	<1.24.2	show Affected versions of urllib3 are vulnerable Improper Certificate Validation. Urllib3 mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections succeeding in situations where a verification failure is the correct outcome. This is related to the use of the ssl_context, ca_certs, or ca_certs_dir argument.

older