Affected versions of Idna are vulnerable to Denial Of Service via the idna.encode(), where a specially crafted argument could lead to significant resource consumption. In version 3.7, this function has been updated to reject such inputs efficiently, minimizing resource use. A practical workaround involves enforcing a maximum domain name length of 253 characters before encoding, as the vulnerability is triggered by unusually large inputs that normal operations wouldn't encounter.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Babel 2.9.1 includes a fix for CVE-2021-42771: Babel.Locale in Babel before 2.9.1 allows attackers to load arbitrary locale .dat files (containing serialized Python objects) via directory traversal, leading to code execution.
https://github.com/python-babel/babel/pull/782

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Bleach 3.3.0 includes a fix for CVE-2021-23980: A mutation XSS affects users calling bleach.clean with all of: svg or math in the allowed tags p or br in allowed tags style, title, noscript, script, textarea, noframes, iframe, or xmp in allowed tags the keyword argument strip_comments=False Note: none of the above tags are in the default allowed tags and strip_comments defaults to True.

Bleach 3.1.4 includes a fix for CVE-2020-6817: bleach.clean behavior parsing style attributes could result in a regular expression denial of service (ReDoS). Calls to bleach.clean with an allowed tag with an allowed style attribute are vulnerable to ReDoS. For example, bleach.clean(..., attributes={'a': ['style']}).

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe.

Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Pygments 2.15.0 includes a fix for CVE-2022-40896: The regular expressions used when parsing Smithy, SQL/SQL+Jinja, and Java properties files were discovered to be vulnerable. As a result, pygmentizing a maliciously-crafted file of these kinds would have resulted in high resources consumption or crashing of the application.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages-part-2

Pygments 2.7.4 includes a fix for CVE-2021-20270: An infinite loop in SMLLexer in Pygments versions 1.5 to 2.7.3 may lead to denial of service when performing syntax highlighting of a Standard ML (SML) source file, as demonstrated by input that only contains the "exception" keyword.

Pygments 2.7.4 includes a fix for CVE-2021-27291: In pygments 1.1+, fixed in 2.7.4, the lexers used to parse programming languages rely heavily on regular expressions. Some of the regular expressions have exponential or cubic worst-case complexity and are vulnerable to ReDoS. By crafting malicious input, an attacker can cause a denial of service.

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.

Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion.

Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store.
https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

Affected versions of Idna are vulnerable to Denial Of Service via the idna.encode(), where a specially crafted argument could lead to significant resource consumption. In version 3.7, this function has been updated to reject such inputs efficiently, minimizing resource use. A practical workaround involves enforcing a maximum domain name length of 253 characters before encoding, as the vulnerability is triggered by unusually large inputs that normal operations wouldn't encounter.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Babel 2.9.1 includes a fix for CVE-2021-42771: Babel.Locale in Babel before 2.9.1 allows attackers to load arbitrary locale .dat files (containing serialized Python objects) via directory traversal, leading to code execution.
https://github.com/python-babel/babel/pull/782

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Bleach 3.3.0 includes a fix for CVE-2021-23980: A mutation XSS affects users calling bleach.clean with all of: svg or math in the allowed tags p or br in allowed tags style, title, noscript, script, textarea, noframes, iframe, or xmp in allowed tags the keyword argument strip_comments=False Note: none of the above tags are in the default allowed tags and strip_comments defaults to True.

Bleach 3.1.4 includes a fix for CVE-2020-6817: bleach.clean behavior parsing style attributes could result in a regular expression denial of service (ReDoS). Calls to bleach.clean with an allowed tag with an allowed style attribute are vulnerable to ReDoS. For example, bleach.clean(..., attributes={'a': ['style']}).

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe.

Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Pygments 2.15.0 includes a fix for CVE-2022-40896: The regular expressions used when parsing Smithy, SQL/SQL+Jinja, and Java properties files were discovered to be vulnerable. As a result, pygmentizing a maliciously-crafted file of these kinds would have resulted in high resources consumption or crashing of the application.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages-part-2

Pygments 2.7.4 includes a fix for CVE-2021-20270: An infinite loop in SMLLexer in Pygments versions 1.5 to 2.7.3 may lead to denial of service when performing syntax highlighting of a Standard ML (SML) source file, as demonstrated by input that only contains the "exception" keyword.

Pygments 2.7.4 includes a fix for CVE-2021-27291: In pygments 1.1+, fixed in 2.7.4, the lexers used to parse programming languages rely heavily on regular expressions. Some of the regular expressions have exponential or cubic worst-case complexity and are vulnerable to ReDoS. By crafting malicious input, an attacker can cause a denial of service.

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.

Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion.

Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store.
https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

Affected versions of Idna are vulnerable to Denial Of Service via the idna.encode(), where a specially crafted argument could lead to significant resource consumption. In version 3.7, this function has been updated to reject such inputs efficiently, minimizing resource use. A practical workaround involves enforcing a maximum domain name length of 253 characters before encoding, as the vulnerability is triggered by unusually large inputs that normal operations wouldn't encounter.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Babel 2.9.1 includes a fix for CVE-2021-42771: Babel.Locale in Babel before 2.9.1 allows attackers to load arbitrary locale .dat files (containing serialized Python objects) via directory traversal, leading to code execution.
https://github.com/python-babel/babel/pull/782

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Bleach 3.3.0 includes a fix for CVE-2021-23980: A mutation XSS affects users calling bleach.clean with all of: svg or math in the allowed tags p or br in allowed tags style, title, noscript, script, textarea, noframes, iframe, or xmp in allowed tags the keyword argument strip_comments=False Note: none of the above tags are in the default allowed tags and strip_comments defaults to True.

Bleach 3.1.4 includes a fix for CVE-2020-6817: bleach.clean behavior parsing style attributes could result in a regular expression denial of service (ReDoS). Calls to bleach.clean with an allowed tag with an allowed style attribute are vulnerable to ReDoS. For example, bleach.clean(..., attributes={'a': ['style']}).

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe.

Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Pygments 2.15.0 includes a fix for CVE-2022-40896: The regular expressions used when parsing Smithy, SQL/SQL+Jinja, and Java properties files were discovered to be vulnerable. As a result, pygmentizing a maliciously-crafted file of these kinds would have resulted in high resources consumption or crashing of the application.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages-part-2

Pygments 2.7.4 includes a fix for CVE-2021-20270: An infinite loop in SMLLexer in Pygments versions 1.5 to 2.7.3 may lead to denial of service when performing syntax highlighting of a Standard ML (SML) source file, as demonstrated by input that only contains the "exception" keyword.

Pygments 2.7.4 includes a fix for CVE-2021-27291: In pygments 1.1+, fixed in 2.7.4, the lexers used to parse programming languages rely heavily on regular expressions. Some of the regular expressions have exponential or cubic worst-case complexity and are vulnerable to ReDoS. By crafting malicious input, an attacker can cause a denial of service.

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.

Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion.

Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store.
https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

Affected versions of Idna are vulnerable to Denial Of Service via the idna.encode(), where a specially crafted argument could lead to significant resource consumption. In version 3.7, this function has been updated to reject such inputs efficiently, minimizing resource use. A practical workaround involves enforcing a maximum domain name length of 253 characters before encoding, as the vulnerability is triggered by unusually large inputs that normal operations wouldn't encounter.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Babel 2.9.1 includes a fix for CVE-2021-42771: Babel.Locale in Babel before 2.9.1 allows attackers to load arbitrary locale .dat files (containing serialized Python objects) via directory traversal, leading to code execution.
https://github.com/python-babel/babel/pull/782

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Bleach 3.3.0 includes a fix for CVE-2021-23980: A mutation XSS affects users calling bleach.clean with all of: svg or math in the allowed tags p or br in allowed tags style, title, noscript, script, textarea, noframes, iframe, or xmp in allowed tags the keyword argument strip_comments=False Note: none of the above tags are in the default allowed tags and strip_comments defaults to True.

Bleach 3.1.4 includes a fix for CVE-2020-6817: bleach.clean behavior parsing style attributes could result in a regular expression denial of service (ReDoS). Calls to bleach.clean with an allowed tag with an allowed style attribute are vulnerable to ReDoS. For example, bleach.clean(..., attributes={'a': ['style']}).

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe.

Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Pygments 2.15.0 includes a fix for CVE-2022-40896: The regular expressions used when parsing Smithy, SQL/SQL+Jinja, and Java properties files were discovered to be vulnerable. As a result, pygmentizing a maliciously-crafted file of these kinds would have resulted in high resources consumption or crashing of the application.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages-part-2

Pygments 2.7.4 includes a fix for CVE-2021-20270: An infinite loop in SMLLexer in Pygments versions 1.5 to 2.7.3 may lead to denial of service when performing syntax highlighting of a Standard ML (SML) source file, as demonstrated by input that only contains the "exception" keyword.

Pygments 2.7.4 includes a fix for CVE-2021-27291: In pygments 1.1+, fixed in 2.7.4, the lexers used to parse programming languages rely heavily on regular expressions. Some of the regular expressions have exponential or cubic worst-case complexity and are vulnerable to ReDoS. By crafting malicious input, an attacker can cause a denial of service.

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.

Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

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 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 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

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 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 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 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

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 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 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

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 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.

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 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 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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 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

The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.

Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

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.

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 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

Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion.

Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store.
https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

Affected versions of Idna are vulnerable to Denial Of Service via the idna.encode(), where a specially crafted argument could lead to significant resource consumption. In version 3.7, this function has been updated to reject such inputs efficiently, minimizing resource use. A practical workaround involves enforcing a maximum domain name length of 253 characters before encoding, as the vulnerability is triggered by unusually large inputs that normal operations wouldn't encounter.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

Py 1.10.0 includes a fix for CVE-2020-29651: A denial of service via regular expression in the py.path.svnwc component of py (aka python-py) through 1.9.0 could be used by attackers to cause a compute-time denial of service attack by supplying malicious input to the blame functionality.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Babel 2.9.1 includes a fix for CVE-2021-42771: Babel.Locale in Babel before 2.9.1 allows attackers to load arbitrary locale .dat files (containing serialized Python objects) via directory traversal, leading to code execution.
https://github.com/python-babel/babel/pull/782

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Bleach 3.3.0 includes a fix for CVE-2021-23980: A mutation XSS affects users calling bleach.clean with all of: svg or math in the allowed tags p or br in allowed tags style, title, noscript, script, textarea, noframes, iframe, or xmp in allowed tags the keyword argument strip_comments=False Note: none of the above tags are in the default allowed tags and strip_comments defaults to True.

Bleach 3.1.4 includes a fix for CVE-2020-6817: bleach.clean behavior parsing style attributes could result in a regular expression denial of service (ReDoS). Calls to bleach.clean with an allowed tag with an allowed style attribute are vulnerable to ReDoS. For example, bleach.clean(..., attributes={'a': ['style']}).

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

gRPC contains a vulnerability whereby a client can cause a termination of connection between a HTTP2 proxy and a gRPC server: a base64 encoding error for `-bin` suffixed headers will result in a disconnection by the gRPC server, but is typically allowed by HTTP2 proxies.

gRPC has a vulnerability linked to hpack table accounting errors, causing potential unwanted disconnects between clients and servers. Identified vectors include unbounded memory buffering and CPU consumption within the HPACK parser, leading to denial-of-service (DOS) attacks. The CPU issue stems from excessive copying, resulting in inefficient parsing. Memory issues arise from delayed header size checks, allowing large strings to be buffered, and a quirk in HPACK's integer encoding, permitting infinite zero-padding. Additionally, metadata overflow checks per frame could enable infinite buffering, compromising gRPC's stability and security.

Grpcio 1.53.2, 1.54.3, 1.55.3 and 1.56.2 include a fix for CVE-2023-4785: Lack of error handling in the TCP server in Google's gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected.
https://github.com/grpc/grpc/pull/33656

Grpcio 1.53.0 includes a fix for a Connection Confusion vulnerability. When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration.
https://github.com/advisories/GHSA-cfgp-2977-2fmm

Grpcio 1.53.0 includes a fix for a Reachable Assertion vulnerability. 
https://github.com/advisories/GHSA-6628-q6j9-w8vg

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

This affects the package jinja2 from 0.0.0 and before 2.11.3. The ReDoS vulnerability is mainly due to the '_punctuation_re regex' operator and its use of multiple wildcards. The last wildcard is the most exploitable as it searches for trailing punctuation. This issue can be mitigated by Markdown to format user content instead of the urlize filter, or by implementing request timeouts and limiting process memory.

Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe.

Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Pygments 2.15.0 includes a fix for CVE-2022-40896: The regular expressions used when parsing Smithy, SQL/SQL+Jinja, and Java properties files were discovered to be vulnerable. As a result, pygmentizing a maliciously-crafted file of these kinds would have resulted in high resources consumption or crashing of the application.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages-part-2

Pygments 2.7.4 includes a fix for CVE-2021-20270: An infinite loop in SMLLexer in Pygments versions 1.5 to 2.7.3 may lead to denial of service when performing syntax highlighting of a Standard ML (SML) source file, as demonstrated by input that only contains the "exception" keyword.

Pygments 2.7.4 includes a fix for CVE-2021-27291: In pygments 1.1+, fixed in 2.7.4, the lexers used to parse programming languages rely heavily on regular expressions. Some of the regular expressions have exponential or cubic worst-case complexity and are vulnerable to ReDoS. By crafting malicious input, an attacker can cause a denial of service.

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the protobuf package are vulnerable to Denial of Service (DoS) due to missing recursion depth accounting that allows the max_recursion_depth limit to be bypassed. The google.protobuf.json_format.ParseDict() parser fails to increment or enforce max_recursion_depth when traversing nested google.protobuf.Any messages in its internal Any-handling logic, allowing attacker-controlled JSON to recurse far deeper than intended.

Affected versions of this package are vulnerable to a potential Denial of Service (DoS) attack due to unbounded recursion when parsing untrusted Protocol Buffers data. The pure-Python implementation fails to enforce recursion depth limits when processing recursive groups, recursive messages, or a series of SGROUP tags, leading to stack overflow conditions that can crash the application by exceeding Python's recursion limit.

Protobuf 3.15.0 includes a fix for CVE-2021-22570: Nullptr dereference when a null char is present in a proto symbol. The symbol is parsed incorrectly, leading to an unchecked call into the proto file's name during generation of the resulting error message. Since the symbol is incorrectly parsed, the file is nullptr.

Protobuf 3.18.3, 3.19.5, 3.20.2 and 4.21.6 include a fix for CVE-2022-1941: A parsing vulnerability for the MessageSet type in the ProtocolBuffers versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 3.21.5 for protobuf-cpp, and versions prior to and including 3.16.1, 3.17.3, 3.18.2, 3.19.4, 3.20.1 and 4.21.5 for protobuf-python can lead to out of memory failures. A specially crafted message with multiple key-value per elements creates parsing issues, and can lead to a Denial of Service against services receiving unsanitized input.
https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-8gq9-2x98-w8hf

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.

Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

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 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 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

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 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 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 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

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 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 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

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 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

Cryptography 41.0.5 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.4, that includes a security fix.

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 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 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

Cryptography 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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 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

The cryptography package before 41.0.2 for Python mishandles SSH certificates that have critical options.

Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

Cryptography 39.0.1 updates its dependency 'OpenSSL' to v3.0.8 to include security fixes.
https://github.com/pyca/cryptography/issues/8229

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.

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 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

Certifi 2022.12.07 includes a fix for CVE-2022-23491: Certifi 2022.12.07 removes root certificates from "TrustCor" from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion.

Certifi 2023.07.22 includes a fix for CVE-2023-37920: Certifi prior to version 2023.07.22 recognizes "e-Tugra" root certificates. e-Tugra's root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store.
https://github.com/certifi/python-certifi/security/advisories/GHSA-xqr8-7jwr-rhp7

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.

Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.

Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.

Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.

** DISPUTED ** Py throughout 1.11.0 allows remote attackers to conduct a ReDoS (Regular expression Denial of Service) attack via a Subversion repository with crafted info data because the InfoSvnCommand argument is mishandled.
https://github.com/pytest-dev/py/issues/287

A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the `Path` module in both zipp and zipfile, such as `joinpath`, the overloaded division operator, and `iterdir`. Although the infinite loop is not resource exhaustive, it prevents the application from responding.

Tqdm version 4.66.3 addresses CVE-2024-34062, a vulnerability where optional non-boolean CLI arguments like `--delim`, `--buf-size`, and `--manpath` were passed through Python's `eval`, allowing for arbitrary code execution. This security risk, only locally exploitable, has been mitigated in this release. Users are advised to upgrade to version 4.66.3 immediately as there are no workarounds for this issue.

Affected versions of the python-ecdsa package are vulnerable to Denial of Service due to improper validation of DER length fields in malformed private keys. The ecdsa.der.remove_octet_string() function accepts truncated DER input when the declared length exceeds the available buffer, and this malformed data can then reach SigningKey.from_der(), which may raise an internal IndexError instead of safely rejecting the input with UnexpectedDER or ValueError.

The python-ecdsa library, which implements ECDSA cryptography in Python, is vulnerable to the Minerva attack (CVE-2024-23342). This vulnerability arises because scalar multiplication is not performed in constant time, affecting ECDSA signatures, key generation, and ECDH operations. ECDSA signature verification remains unaffected. The project maintainers have stated that there is no plan to release a fix for this vulnerability, citing their security policy:
"As stated in the security policy, side-channel vulnerabilities are outside the scope of the project. This is not due to a lack of interest in side-channel secure implementations but rather because the main goal of the project is to be pure Python. Implementing side-channel-free code in pure Python is impossible. Therefore, we do not plan to release a fix for this vulnerability."
NOTE: The specs we include in this advisory differ from the publicly available on other sources. That's because research by Safety CLI Cybersecurity Team confirms that there is no plan to address this vulnerability.

Ecdsa does not protects against side-channel attacks. This is because Python does not provide side-channel secure primitives (with the exception of hmac.compare_digest()), making side-channel secure programming impossible. For a sophisticated attacker observing just one operation with a private key will be sufficient to completely reconstruct the private key.
https://pypi.org/project/ecdsa/#Security

Prior to 3.1.6, an oversight in how the Jinja sandboxed environment interacts with the |attr filter allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to use the |attr filter to get a reference to a string's plain format method, bypassing the sandbox. After the fix, the |attr filter no longer bypasses the environment's attribute lookup. This vulnerability is fixed in 3.1.6.

A vulnerability in the Jinja compiler allows an attacker who can control both the content and filename of a template to execute arbitrary Python code, bypassing Jinja's sandbox protections. To exploit this vulnerability, an attacker must have the ability to manipulate both the template's filename and its contents. The risk depends on the application's specific use case. This issue affects applications that render untrusted templates where the attacker can determine the template filename, potentially leading to severe security breaches.

An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker who controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

Sphinx 3.0.4 updates jQuery version from 3.4.1 to 3.5.1 for security reasons.

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 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

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Wheel 0.38.1 includes a fix for CVE-2022-40898: An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlier allows remote attackers to cause a denial of service via attacker controlled input to wheel cli.
https://pyup.io/posts/pyup-discovers-redos-vulnerabilities-in-top-python-packages

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.

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.

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'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.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.26.5 includes a fix for CVE-2021-33503: When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.
https://github.com/advisories/GHSA-q2q7-5pp4-w6pg

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 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.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

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of Requests are vulnerable to proxy credential leakage. When redirected to an HTTPS endpoint, the Proxy-Authorization header is forwarded to the destination server due to the use of rebuild_proxies to reattach the header. This may allow a malicious actor to exfiltrate sensitive information.

Affected versions of Requests, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. Requests 2.32.0 fixes the issue, but versions 2.32.0 and 2.32.1 were yanked due to conflicts with CVE-2024-35195 mitigation.

Requests is an HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Virtualenv version 20.21.0 addresses a race condition in `virtualenv.cli_run` where a `FileNotFoundError` could occur for a JSON file in `pypa/virtualenv/py_info/1`. This error happens if the underlying interpreter is updated, causing the JSON file to be deleted and rewritten.

Affected versions of the virtualenv package are vulnerable to Command Injection due to improper quoting of template string placeholders in activation scripts. The vulnerability exists in the ViaTemplateActivator class, where magic template strings like __VIRTUAL_ENV__ are replaced in shell activation scripts without proper escaping or quoting, allowing shell metacharacters to be interpreted as commands during string substitution. An attacker can exploit this vulnerability by creating a virtual environment with a specially crafted directory name containing shell commands (such as "';uname -a;':"), which will be executed when the activation script is sourced, resulting in arbitrary command execution with the privileges of the user activating the virtual environment.

Affected versions of the virtualenv package (up to and including 20.36.1) are vulnerable to Race Condition (TOCTOU) attacks due to non-atomic directory creation that is performed using check-then-act filesystem logic. The issue occurs in virtualenv’s directory creation operations for its app_data path and related lock file handling, where a directory existence check can be raced so a symlink is inserted before the subsequent creation or access step, redirecting operations to an unintended location.