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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.

Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code.
https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html

Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.
https://github.com/python-pillow/Pillow/pull/7244

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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.

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

Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store.

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.

Affected versions of the virtualenv package are vulnerable to command injection. This vulnerability could allow an attacker to execute arbitrary commands by exploiting improperly quoted string placeholders in activation scripts. The vulnerable functions include various shell activation scripts where placeholders like __VIRTUAL_ENV__ are used. The exploitability depends on the ability to control the input to these placeholders. Users are advised to update to the version where a quoting mechanism has been implemented to mitigate this risk. This vulnerability is specific to environments where shell scripts are used for virtual environment activation. The issue is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.

Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code.
https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html

Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.
https://github.com/python-pillow/Pillow/pull/7244

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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 the virtualenv package are vulnerable to command injection. This vulnerability could allow an attacker to execute arbitrary commands by exploiting improperly quoted string placeholders in activation scripts. The vulnerable functions include various shell activation scripts where placeholders like __VIRTUAL_ENV__ are used. The exploitability depends on the ability to control the input to these placeholders. Users are advised to update to the version where a quoting mechanism has been implemented to mitigate this risk. This vulnerability is specific to environments where shell scripts are used for virtual environment activation. The issue is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.

Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code.
https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html

Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.
https://github.com/python-pillow/Pillow/pull/7244

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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.

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

Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store.

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.

Affected versions of the virtualenv package are vulnerable to command injection. This vulnerability could allow an attacker to execute arbitrary commands by exploiting improperly quoted string placeholders in activation scripts. The vulnerable functions include various shell activation scripts where placeholders like __VIRTUAL_ENV__ are used. The exploitability depends on the ability to control the input to these placeholders. Users are advised to update to the version where a quoting mechanism has been implemented to mitigate this risk. This vulnerability is specific to environments where shell scripts are used for virtual environment activation. The issue is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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.

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

Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store.

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.

Affected versions of the virtualenv package are vulnerable to command injection. This vulnerability could allow an attacker to execute arbitrary commands by exploiting improperly quoted string placeholders in activation scripts. The vulnerable functions include various shell activation scripts where placeholders like __VIRTUAL_ENV__ are used. The exploitability depends on the ability to control the input to these placeholders. Users are advised to update to the version where a quoting mechanism has been implemented to mitigate this risk. This vulnerability is specific to environments where shell scripts are used for virtual environment activation. The issue is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.

Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code.
https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html

Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.
https://github.com/python-pillow/Pillow/pull/7244

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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.

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

Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store.

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.

Affected versions of the virtualenv package are vulnerable to command injection. This vulnerability could allow an attacker to execute arbitrary commands by exploiting improperly quoted string placeholders in activation scripts. The vulnerable functions include various shell activation scripts where placeholders like __VIRTUAL_ENV__ are used. The exploitability depends on the ability to control the input to these placeholders. Users are advised to update to the version where a quoting mechanism has been implemented to mitigate this risk. This vulnerability is specific to environments where shell scripts are used for virtual environment activation. The issue is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.

Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code.
https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html

Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.
https://github.com/python-pillow/Pillow/pull/7244

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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.

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

Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store.

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.

Affected versions of the virtualenv package are vulnerable to command injection. This vulnerability could allow an attacker to execute arbitrary commands by exploiting improperly quoted string placeholders in activation scripts. The vulnerable functions include various shell activation scripts where placeholders like __VIRTUAL_ENV__ are used. The exploitability depends on the ability to control the input to these placeholders. Users are advised to update to the version where a quoting mechanism has been implemented to mitigate this risk. This vulnerability is specific to environments where shell scripts are used for virtual environment activation. The issue is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.

Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code.
https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html

Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.
https://github.com/python-pillow/Pillow/pull/7244

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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.

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

Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store.

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.

Affected versions of the virtualenv package are vulnerable to command injection. This vulnerability could allow an attacker to execute arbitrary commands by exploiting improperly quoted string placeholders in activation scripts. The vulnerable functions include various shell activation scripts where placeholders like __VIRTUAL_ENV__ are used. The exploitability depends on the ability to control the input to these placeholders. Users are advised to update to the version where a quoting mechanism has been implemented to mitigate this risk. This vulnerability is specific to environments where shell scripts are used for virtual environment activation. The issue is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.

Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code.
https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html

Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.
https://github.com/python-pillow/Pillow/pull/7244

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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.

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

Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store.

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.

Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code.
https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html

Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.
https://github.com/python-pillow/Pillow/pull/7244

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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.

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

Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store.

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.

Affected versions of the virtualenv package are vulnerable to command injection. This vulnerability could allow an attacker to execute arbitrary commands by exploiting improperly quoted string placeholders in activation scripts. The vulnerable functions include various shell activation scripts where placeholders like __VIRTUAL_ENV__ are used. The exploitability depends on the ability to control the input to these placeholders. Users are advised to update to the version where a quoting mechanism has been implemented to mitigate this risk. This vulnerability is specific to environments where shell scripts are used for virtual environment activation. The issue is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 10.3.0 introduces a security update addressing CVE-2024-28219 by replacing certain functions with strncpy to prevent buffer overflow issues.

Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).

Pillow is potentially vulnerable to DoS attacks through PIL.ImageFont.ImageFont.getmask(). A decompression bomb check has also been added to the affected function.

Pillow is affected by an arbitrary code execution vulnerability. If an attacker has control over the keys passed to the environment argument of PIL.ImageMath.eval(), they may be able to execute arbitrary code.
https://pillow.readthedocs.io/en/stable/releasenotes/10.2.0.html

Pillow 10.0.0 includes a fix for CVE-2023-44271: Denial of Service that uncontrollably allocates memory to process a given task, potentially causing a service to crash by having it run out of memory. This occurs for truetype in ImageFont when textlength in an ImageDraw instance operates on a long text argument.
https://github.com/python-pillow/Pillow/pull/7244

OAuthLib 3.2.1 includes a fix for CVE-2022-36087: In OAuthLib versions 3.1.1 until 3.2.1, an attacker providing malicious redirect uri can cause denial of service. An attacker can also leverage usage of 'uri_validate' functions depending where it is used. OAuthLib applications using OAuth2.0 provider support or use directly 'uri_validate' are affected by this issue. There are no known workarounds.
https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7

Sqlparse 0.4.4 includes a fix for CVE-2023-30608: Parser contains a regular expression that is vulnerable to ReDOS (Regular Expression Denial of Service).
https://github.com/andialbrecht/sqlparse/security/advisories/GHSA-rrm6-wvj7-cwh2

Sqlparse 0.5.0 addresses a potential denial of service (DoS) vulnerability related to recursion errors in deeply nested SQL statements. To mitigate this issue, the update replaces recursion errors with a general SQLParseError, improving the resilience and stability of the parsing process.

Urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and before 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime, utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behaviour. This issue has been patched in version 2.5.0.

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

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.

Gunicorn version 21.2.0 does not properly validate the value of the 'Transfer-Encoding' header as specified in the RFC standards, which leads to the default fallback method of 'Content-Length,' making it vulnerable to TE.CL request smuggling. This vulnerability can lead to cache poisoning, data exposure, session manipulation, SSRF, XSS, DoS, data integrity compromise, security bypass, information leakage, and business logic abuse.

Gunicorn fails to properly validate Transfer-Encoding headers, leading to HTTP Request Smuggling (HRS) vulnerabilities. By crafting requests with conflicting Transfer-Encoding headers, attackers can bypass security restrictions and access restricted endpoints. This issue is due to Gunicorn's handling of Transfer-Encoding headers, where it incorrectly processes requests with multiple, conflicting Transfer-Encoding headers, treating them as chunked regardless of the final encoding specified. This vulnerability allows for a range of attacks including cache poisoning, session manipulation, and data exposure.

A time-based vulnerability in Gunicorn affected versions allows an attacker to disrupt service by manipulating the system clock, causing premature worker timeouts and potential denial-of-service (DoS) conditions. The issue stems from the use of time.time() in the worker timeout logic, which can be exploited if an attacker gains the ability to change the system time.

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

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.

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

Certifi affected versions recognized root certificates from GLOBALTRUST. Certifi patch removes these root certificates from the root store. These certificates are being removed pursuant to an investigation that identified "long-running and unresolved compliance issues" and are also in the process of being removed from Mozilla's trust store.

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.

Affected versions of the virtualenv package are vulnerable to command injection. This vulnerability could allow an attacker to execute arbitrary commands by exploiting improperly quoted string placeholders in activation scripts. The vulnerable functions include various shell activation scripts where placeholders like __VIRTUAL_ENV__ are used. The exploitability depends on the ability to control the input to these placeholders. Users are advised to update to the version where a quoting mechanism has been implemented to mitigate this risk. This vulnerability is specific to environments where shell scripts are used for virtual environment activation. The issue is tracked under CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection').

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.

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.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

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

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

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 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

Cryptography 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 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 starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

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

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 39.0.1 includes a fix for CVE-2022-3996, a DoS vulnerability affecting openssl.
https://github.com/pyca/cryptography/issues/7940

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

Django-grappelli version 3.0.4 has updated its grunt dependency to version 1.5.3. This update addresses a race condition vulnerability identified in CVE-2022-1537, which impacts versions prior to 1.5.2.

Django-grappelli version 3.0.4 updates its grunt dependency to version 1.5.3 to address a path traversal vulnerability identified in CVE-2022-0436, which affects versions prior to 1.5.2.

Django-grappelli 2.15.2 includes a fix for CVE-2021-46898: views/switch.py in django-grappelli before 2.15.2 attempts to prevent external redirection with startswith("/") but this does not consider a protocol-relative URL (e.g., //example.com) attack.
https://github.com/sehmaschine/django-grappelli/issues/975

Python Social Auth is a social authentication/registration mechanism. Prior to version 5.4.1, due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. This issue has been addressed by a fix released in version 5.4.1. An immediate workaround would be to change collation of the affected field. See CVE-2024-32879.

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

Affected versions of pyjwt are vulnerable to Partial Comparison (CWE-187). This flaw allows attackers to bypass issuer (iss) verification by providing partial matches, potentially granting unauthorized access. The vulnerability arises in the decode method of api_jwt.py, where issuer validation incorrectly treats strings as sequences, leading to partial matches (e.g., "abc" being accepted for "__abc__"). Exploiting this requires crafting JWTs with partially matching iss claims, which is straightforward.

PyJWT 2.4.0 includes a fix for CVE-2022-29217: An attacker submitting the JWT token can choose the used signing algorithm. The PyJWT library requires that the application chooses what algorithms are supported. The application can specify 'jwt.algorithms.get_default_algorithms()' to get support for all algorithms, or specify a single algorithm. The issue is not that big as 'algorithms=jwt.algorithms.get_default_algorithms()' has to be used. As a workaround, always be explicit with the algorithms that are accepted and expected when decoding.

Affected versions of Django are affected by a directory-traversal vulnerability in the Storage.save() method. Derived classes of the django.core.files.storage.Storage base class that overrides the generate_filename() method without replicating the file path validations existing in the parent class could allow for directory traversal via certain inputs when calling save(). This could enable an attacker to manipulate file paths and access unintended directories.

An issue was discovered in Django 5.2 before 5.2.3, 5.1 before 5.1.11, and 4.2 before 4.2.23. Internal HTTP response logging does not escape request.path, which allows remote attackers to potentially manipulate log output via crafted URLs. This may lead to log injection or forgery when logs are viewed in terminals or processed by external systems.

Affected versions of Django are vulnerable to potential regular expression denial-of-service (REDoS). django.utils.text.Truncator.words() method (with html=True) and truncatewords_html template filter were subject to a potential regular expression denial-of-service attack using a suitably crafted string (follow up to CVE-2019-14232 and CVE-2023-43665).

Affected versions of Django are affected by a username enumeration vulnerability caused by timing differences in the django.contrib.auth.backends.ModelBackend.authenticate() method. This method allowed remote attackers to enumerate users through a timing attack involving login requests for users with unusable passwords. The timing difference in the authentication process exposed whether a username was valid or not, potentially aiding attackers in gaining unauthorized access.

An issue was discovered in Django 4.2 before 4.2.21, 5.1 before 5.1.9, and 5.2 before 5.2.1. The django.utils.html.strip_tags() function is vulnerable to a potential denial-of-service (slow performance) when processing inputs containing large sequences of incomplete HTML tags. The template filter striptags is also vulnerable, because it is built on top of strip_tags().

Affected versions of Django has a potential SQL injection vulnerability in the QuerySet.values() and QuerySet.values_list() methods. When used on models with a JSONField, these methods are susceptible to SQL injection through column aliases if a crafted JSON object key is passed as an argument.

Affected versions of Django are affected by a potential denial-of-service vulnerability in the django.utils.html.urlize() function. The urlize and urlizetrunc template filters were susceptible to a denial-of-service attack via certain inputs containing many brackets. An attacker could exploit this vulnerability to cause significant delays or crashes in the affected application.

A security vulnerability has been discovered in certain versions of Django, affecting the password reset functionality. The PasswordResetForm class in django.contrib.auth.forms inadvertently allowed attackers to enumerate user email addresses by exploiting unhandled exceptions during the email sending process. This could be done by issuing password reset requests and observing the responses. Django has implemented a fix where these exceptions are now caught and logged using the django.contrib.auth logger, preventing potential information leakage through error responses.

In Django 3.2 before 3.2.16, 4.0 before 4.0.8, and 4.1 before 4.1.2, internationalized URLs were subject to a potential denial of service attack via the locale parameter, which is treated as a regular expression.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28346: An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and extra() methods are subject to SQL injection in column aliases via a crafted dictionary (with dictionary expansion) as the passed **kwargs.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Affected versions of Django are vulnerable to potential Denial of Service via certain inputs with a very large number of Unicode characters in django.utils.encoding.uri_to_iri().

Django 2.2.27, 3.2.12 and 4.0.2 include a fix for CVE-2022-23833: Denial-of-service possibility in file uploads.
https://www.djangoproject.com/weblog/2022/feb/01/security-releases

Django addresses a memory exhaustion issue in django.utils.numberformat.floatformat(). When floatformat receives a string representation of a number in scientific notation with a large exponent, it could lead to excessive memory consumption. To prevent this, decimals with more than 200 digits are now returned as-is.

Django 4.2.1, 4.1.9 and 3.2.19 include a fix for CVE-2023-31047: In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django's "Uploading multiple files" documentation suggested otherwise.
https://www.djangoproject.com/weblog/2023/may/03/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45115: UserAttributeSimilarityValidator incurred significant overhead in evaluating a submitted password that was artificially large in relation to the comparison values. In a situation where access to user registration was unrestricted, this provided a potential vector for a denial-of-service attack.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service attack due to improper IPv6 validation. The lack of upper limit enforcement for input strings in clean_ipv6_address, is_valid_ipv6_address, and the django.forms.GenericIPAddressField form field allowed attackers to exploit overly long inputs, causing resource exhaustion. The vulnerability is addressed by defining a max_length of 39 characters for affected form fields. The django.db.models.GenericIPAddressField model field was not impacted. Users should upgrade promptly.

A potential denial-of-service vulnerability has been identified in Django's urlize() and urlizetrunc() functions in django.utils.html. This vulnerability can be triggered by inputting huge strings containing a specific sequence of characters.

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45116: An issue was discovered in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1. Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure, or an unintended method call, if passed a suitably crafted key.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases

Django 3.2.17, 4.0.9 and 4.1.6 includes a fix for CVE-2023-23969: In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.
https://www.djangoproject.com/weblog/2023/feb/01/security-releases

Django 3.2.14 and 4.0.6 include a fix for CVE-2022-34265: Potential SQL injection via Trunc(kind) and Extract(lookup_name) arguments.
https://www.djangoproject.com/weblog/2022/jul/04/security-releases

Django affected versions are vulnerable to a potential SQL injection in the HasKey(lhs, rhs) lookup on Oracle databases. The vulnerability arises when untrusted data is directly used as the lhs value in the django.db.models.fields.json.HasKey lookup. However, applications using the jsonfield.has_key lookup with the __ syntax remain unaffected by this issue.

Django 4.1.7, 4.0.10 and 3.2.18 include a fix for CVE-2023-24580: Potential denial-of-service vulnerability in file uploads.
https://www.djangoproject.com/weblog/2023/feb/14/security-releases

Django versions 2.2.25, 3.1.14 and 3.2.10 include a fix for CVE-2021-44420: In Django 2.2 before 2.2.25, 3.1 before 3.1.14, and 3.2 before 3.2.10, HTTP requests for URLs with trailing newlines could bypass upstream access control based on URL paths.
https://www.djangoproject.com/weblog/2021/dec/07/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service (DoS) attack in the `django.utils.html.strip_tags()` method. The vulnerability occurs when the `strip_tags()` method or the `striptags` template filter processes inputs containing large sequences of nested, incomplete HTML entities.

Affected versions of Django are vulnerable to potential denial-of-service in intcomma template filter when used with very long strings.

The {% debug %} template tag in Django 2.2 before 2.2.27, 3.2 before 3.2.12, and 4.0 before 4.0.2 does not properly encode the current context. This may lead to XSS.

Django 2.2.28, 3.2.13 and 4.0.4 include a fix for CVE-2022-28347: A SQL injection issue was discovered in QuerySet.explain() in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. This occurs by passing a crafted dictionary (with dictionary expansion) as the **options argument, and placing the injection payload in an option name.
https://www.djangoproject.com/weblog/2022/apr/11/security-releases

Django 2.2.26, 3.2.11 and 4.0.1 include a fix for CVE-2021-45452: Storage.save in Django 2.2 before 2.2.26, 3.2 before 3.2.11, and 4.0 before 4.0.1 allows directory traversal if crafted filenames are directly passed to it.
https://www.djangoproject.com/weblog/2022/jan/04/security-releases/

Affected versions of Django are vulnerable to a potential denial-of-service in django.utils.text.wrap(). The django.utils.text.wrap() and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings.

Django 4.2.7, 4.1.13 and 3.2.23 include a fix for CVE-2023-46695: Potential denial of service vulnerability in UsernameField on Windows.
https://www.djangoproject.com/weblog/2023/nov/01/security-releases

Django has a potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc functions, along with AdminURLFieldWidget, are vulnerable to denial-of-service attacks when handling inputs with a very large number of Unicode characters.

Affected versions of Django are potentially vulnerable to denial-of-service via the get_supported_language_variant() method. This method was susceptible to a denial-of-service attack when used with very long strings containing specific characters. Exploiting this vulnerability could cause significant delays or crashes in the affected application, potentially leading to service disruption.

Affected versions of Django are vulnerable to Denial-of-Service via django.utils.text.Truncator. The django.utils.text.Truncator chars() and words() methods (when used with html=True) are subject to a potential DoS (denial of service) attack via certain inputs with very long, potentially malformed HTML text. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which are thus also vulnerable. NOTE: this issue exists because of an incomplete fix for CVE-2019-14232.

Affected versions of Django are vulnerable to a potential ReDoS (regular expression denial of service) in EmailValidator and URLValidator via a very large number of domain name labels of emails and URLs.

Django 3.2.15 and 4.0.7 include a fix for CVE-2022-36359: An issue was discovered in the HTTP FileResponse class in Django 3.2 before 3.2.15 and 4.0 before 4.0.7. An application is vulnerable to a reflected file download (RFD) attack that sets the Content-Disposition header of a FileResponse when the filename is derived from user-supplied input.
https://www.djangoproject.com/weblog/2022/aug/03/security-releases

Pillow 9.0.0 ensures JpegImagePlugin stops at the end of a truncated file to avoid Denial of Service attacks.
https://github.com/python-pillow/Pillow/pull/5921
https://github.com/advisories/GHSA-4fx9-vc88-q2xc

Pillow 10.0.1 updates its C dependency 'libwebp' to 1.3.2 to include a fix for a high-risk vulnerability.
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.1.html

Pillow 9.0.0 excludes carriage return in PDF regex to help prevent ReDoS.
https://github.com/python-pillow/Pillow/pull/5912
https://github.com/python-pillow/Pillow/commit/43b800d933c996226e4d7df00c33fcbe46d97363

Pillow before 9.0.1 allows attackers to delete files because spaces in temporary pathnames are mishandled.

Pillow 9.0.0 includes a fix for CVE-2022-22815: path_getbbox in path.c in Pillow before 9.0.0 improperly initializes ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling

Pillow 9.0.1 includes a fix for CVE-2022-22817: PIL.ImageMath.eval in Pillow before 9.0.0 allows evaluation of arbitrary expressions, such as ones that use the Python exec method. A first patch was issued for version 9.0.0 but it did not prevent builtins available to lambda expressions.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.1.html#security

Pillow 9.0.0 includes a fix for CVE-2022-22816: path_getbbox in path.c in Pillow before 9.0.0 has a buffer over-read during initialization of ImagePath.Path.
https://pillow.readthedocs.io/en/stable/releasenotes/9.0.0.html#fixed-imagepath-path-array-handling