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

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 this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of control characters in column aliases within FilteredRelation. The FilteredRelation class fails to properly sanitize column aliases containing control characters when used with QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias() via dictionary expansion (**kwargs).

Affected versions of the Django package are vulnerable to SQL Injection due to improper sanitization of band index parameters in PostGIS raster lookups. The raster lookup functionality in Django's GIS module fails to properly validate or escape untrusted data used as a band index when performing spatial queries against PostGIS databases.

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

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. 
https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314

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

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.

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to quadratic time complexity during HTML parsing in text truncation methods. The django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True), as well as the truncatechars_html and truncatewords_html template filters, exhibit quadratic time complexity when processing inputs containing a large number of unmatched HTML end tags.

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/

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.

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

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

CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.

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 (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 the Django package are vulnerable to Information Disclosure (Timing Attack) due to non-constant-time comparison in the mod_wsgi authentication handler. The django.contrib.auth.handlers.modwsgi.check_password() function does not perform user existence checks in constant time, allowing response timing differences to reveal whether usernames exist.

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 fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

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.

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

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.

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.

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.

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

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

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

Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.

CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.

Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.

Affected versions of this package are vulnerable to Time-of-Check Time-of-Use (TOCTOU) Race Condition. The file locking mechanism in SoftFileLock._acquire() performs permission validation before file creation without using the O_NOFOLLOW flag, leading to a race window where attackers with local access can create symlinks that redirect lock operations to arbitrary files. An attacker can exploit this vulnerability by creating a malicious symlink during the brief window between permission check and file creation, causing the lock to operate on unintended target files and potentially enabling unauthorized access or file corruption.

Affected versions of this package are vulnerable to a TOCTOU (Time-of-Check to Time-of-Use) symlink vulnerability due to improper handling of symlinks during lock file creation. The vulnerability exists because the package does not adequately check for symlink manipulation between the time the lock file path is checked and the time it is used. An attacker can exploit this vulnerability by creating a malicious symlink, potentially leading to unauthorized access or modification of files, which could compromise the integrity and security of the system.

Affected versions of the filelock package are vulnerable to a Time-of-Check Time-of-Use (TOCTOU) Race Condition due to a race window between a write-permission check and lock file creation that does not prevent symlink substitution. The flaw is in filelock.SoftFileLock in src/filelock/_soft.py, where _acquire() calls raise_on_not_writable_file() and then performs os.open() on the lock path, allowing the filesystem state to change between the check and the use.

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

Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts.

**Note:** This issue is due to an incomplete fix for CVE-2024-4340.

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.

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

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.

Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.

Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f

Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False.
This vulnerability is specific to Python's urllib3 library.

urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

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.

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

Affected versions of Requests, 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.

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.

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

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

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

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

Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.

Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.

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

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

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

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230719.txt

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

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 41.0.3  updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230714.txt

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

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

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

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

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

Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

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

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.

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

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

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

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix.
https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512

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 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 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 the social-auth-app-django package are vulnerable to Authentication Bypass due to unintended email-based account association during the authentication pipeline. In social_django.storage.create_user (invoked by social_core.pipeline.user.create_user), an IntegrityError during user creation triggers a fallback that returns an existing User looked up by e-mail, effectively performing social_core.pipeline.social_auth.associate_by_email even when that step is disabled.

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

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 this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of control characters in column aliases within FilteredRelation. The FilteredRelation class fails to properly sanitize column aliases containing control characters when used with QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias() via dictionary expansion (**kwargs).

Affected versions of the Django package are vulnerable to SQL Injection due to improper sanitization of band index parameters in PostGIS raster lookups. The raster lookup functionality in Django's GIS module fails to properly validate or escape untrusted data used as a band index when performing spatial queries against PostGIS databases.

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

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. 
https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314

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

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.

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to quadratic time complexity during HTML parsing in text truncation methods. The django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True), as well as the truncatechars_html and truncatewords_html template filters, exhibit quadratic time complexity when processing inputs containing a large number of unmatched HTML end tags.

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/

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.

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

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

CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.

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 (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 the Django package are vulnerable to Information Disclosure (Timing Attack) due to non-constant-time comparison in the mod_wsgi authentication handler. The django.contrib.auth.handlers.modwsgi.check_password() function does not perform user existence checks in constant time, allowing response timing differences to reveal whether usernames exist.

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 fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

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.

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

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.

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.

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.

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

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

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

Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.

CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.

Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.

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

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.

Affected versions of this package are vulnerable to Time-of-Check Time-of-Use (TOCTOU) Race Condition. The file locking mechanism in SoftFileLock._acquire() performs permission validation before file creation without using the O_NOFOLLOW flag, leading to a race window where attackers with local access can create symlinks that redirect lock operations to arbitrary files. An attacker can exploit this vulnerability by creating a malicious symlink during the brief window between permission check and file creation, causing the lock to operate on unintended target files and potentially enabling unauthorized access or file corruption.

Affected versions of this package are vulnerable to a TOCTOU (Time-of-Check to Time-of-Use) symlink vulnerability due to improper handling of symlinks during lock file creation. The vulnerability exists because the package does not adequately check for symlink manipulation between the time the lock file path is checked and the time it is used. An attacker can exploit this vulnerability by creating a malicious symlink, potentially leading to unauthorized access or modification of files, which could compromise the integrity and security of the system.

Affected versions of the filelock package are vulnerable to a Time-of-Check Time-of-Use (TOCTOU) Race Condition due to a race window between a write-permission check and lock file creation that does not prevent symlink substitution. The flaw is in filelock.SoftFileLock in src/filelock/_soft.py, where _acquire() calls raise_on_not_writable_file() and then performs os.open() on the lock path, allowing the filesystem state to change between the check and the use.

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

Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts.

**Note:** This issue is due to an incomplete fix for CVE-2024-4340.

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.

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

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.

Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.

Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f

Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False.
This vulnerability is specific to Python's urllib3 library.

urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

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.

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

Affected versions of Requests, 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.

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.

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

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

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

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

Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.

Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.

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

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

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

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230719.txt

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

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 41.0.3  updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230714.txt

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

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

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

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

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

Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

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

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.

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

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

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

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix.
https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512

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 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 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 the social-auth-app-django package are vulnerable to Authentication Bypass due to unintended email-based account association during the authentication pipeline. In social_django.storage.create_user (invoked by social_core.pipeline.user.create_user), an IntegrityError during user creation triggers a fallback that returns an existing User looked up by e-mail, effectively performing social_core.pipeline.social_auth.associate_by_email even when that step is disabled.

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

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 this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of control characters in column aliases within FilteredRelation. The FilteredRelation class fails to properly sanitize column aliases containing control characters when used with QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias() via dictionary expansion (**kwargs).

Affected versions of the Django package are vulnerable to SQL Injection due to improper sanitization of band index parameters in PostGIS raster lookups. The raster lookup functionality in Django's GIS module fails to properly validate or escape untrusted data used as a band index when performing spatial queries against PostGIS databases.

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

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. 
https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314

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

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.

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to quadratic time complexity during HTML parsing in text truncation methods. The django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True), as well as the truncatechars_html and truncatewords_html template filters, exhibit quadratic time complexity when processing inputs containing a large number of unmatched HTML end tags.

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/

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.

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

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

CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.

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 (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 the Django package are vulnerable to Information Disclosure (Timing Attack) due to non-constant-time comparison in the mod_wsgi authentication handler. The django.contrib.auth.handlers.modwsgi.check_password() function does not perform user existence checks in constant time, allowing response timing differences to reveal whether usernames exist.

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 fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

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.

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

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.

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.

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.

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

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

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

Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.

CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.

Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.

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

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.

Affected versions of this package are vulnerable to Time-of-Check Time-of-Use (TOCTOU) Race Condition. The file locking mechanism in SoftFileLock._acquire() performs permission validation before file creation without using the O_NOFOLLOW flag, leading to a race window where attackers with local access can create symlinks that redirect lock operations to arbitrary files. An attacker can exploit this vulnerability by creating a malicious symlink during the brief window between permission check and file creation, causing the lock to operate on unintended target files and potentially enabling unauthorized access or file corruption.

Affected versions of this package are vulnerable to a TOCTOU (Time-of-Check to Time-of-Use) symlink vulnerability due to improper handling of symlinks during lock file creation. The vulnerability exists because the package does not adequately check for symlink manipulation between the time the lock file path is checked and the time it is used. An attacker can exploit this vulnerability by creating a malicious symlink, potentially leading to unauthorized access or modification of files, which could compromise the integrity and security of the system.

Affected versions of the filelock package are vulnerable to a Time-of-Check Time-of-Use (TOCTOU) Race Condition due to a race window between a write-permission check and lock file creation that does not prevent symlink substitution. The flaw is in filelock.SoftFileLock in src/filelock/_soft.py, where _acquire() calls raise_on_not_writable_file() and then performs os.open() on the lock path, allowing the filesystem state to change between the check and the use.

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

Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts.

**Note:** This issue is due to an incomplete fix for CVE-2024-4340.

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.

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

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.

Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.

Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f

Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False.
This vulnerability is specific to Python's urllib3 library.

urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

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.

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.

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

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

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

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

Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.

Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.

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

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

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

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230719.txt

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

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 41.0.3  updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230714.txt

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

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

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

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

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

Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

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

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.

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

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

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

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix.
https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512

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 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 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 the social-auth-app-django package are vulnerable to Authentication Bypass due to unintended email-based account association during the authentication pipeline. In social_django.storage.create_user (invoked by social_core.pipeline.user.create_user), an IntegrityError during user creation triggers a fallback that returns an existing User looked up by e-mail, effectively performing social_core.pipeline.social_auth.associate_by_email even when that step is disabled.

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

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 this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of control characters in column aliases within FilteredRelation. The FilteredRelation class fails to properly sanitize column aliases containing control characters when used with QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias() via dictionary expansion (**kwargs).

Affected versions of the Django package are vulnerable to SQL Injection due to improper sanitization of band index parameters in PostGIS raster lookups. The raster lookup functionality in Django's GIS module fails to properly validate or escape untrusted data used as a band index when performing spatial queries against PostGIS databases.

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

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. 
https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314

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

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.

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to quadratic time complexity during HTML parsing in text truncation methods. The django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True), as well as the truncatechars_html and truncatewords_html template filters, exhibit quadratic time complexity when processing inputs containing a large number of unmatched HTML end tags.

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/

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.

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

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

CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.

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 (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 the Django package are vulnerable to Information Disclosure (Timing Attack) due to non-constant-time comparison in the mod_wsgi authentication handler. The django.contrib.auth.handlers.modwsgi.check_password() function does not perform user existence checks in constant time, allowing response timing differences to reveal whether usernames exist.

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 fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

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.

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

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.

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.

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.

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

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

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

Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.

CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.

Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.

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

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.

Affected versions of this package are vulnerable to Time-of-Check Time-of-Use (TOCTOU) Race Condition. The file locking mechanism in SoftFileLock._acquire() performs permission validation before file creation without using the O_NOFOLLOW flag, leading to a race window where attackers with local access can create symlinks that redirect lock operations to arbitrary files. An attacker can exploit this vulnerability by creating a malicious symlink during the brief window between permission check and file creation, causing the lock to operate on unintended target files and potentially enabling unauthorized access or file corruption.

Affected versions of this package are vulnerable to a TOCTOU (Time-of-Check to Time-of-Use) symlink vulnerability due to improper handling of symlinks during lock file creation. The vulnerability exists because the package does not adequately check for symlink manipulation between the time the lock file path is checked and the time it is used. An attacker can exploit this vulnerability by creating a malicious symlink, potentially leading to unauthorized access or modification of files, which could compromise the integrity and security of the system.

Affected versions of the filelock package are vulnerable to a Time-of-Check Time-of-Use (TOCTOU) Race Condition due to a race window between a write-permission check and lock file creation that does not prevent symlink substitution. The flaw is in filelock.SoftFileLock in src/filelock/_soft.py, where _acquire() calls raise_on_not_writable_file() and then performs os.open() on the lock path, allowing the filesystem state to change between the check and the use.

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

Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts.

**Note:** This issue is due to an incomplete fix for CVE-2024-4340.

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.

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

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.

Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.

Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f

Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False.
This vulnerability is specific to Python's urllib3 library.

urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

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.

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

Affected versions of Requests, 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.

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.

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

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

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

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

Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.

Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.

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

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

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

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230719.txt

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

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 41.0.3  updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230714.txt

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

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

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

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

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

Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

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

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.

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

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

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

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix.
https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512

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 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 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 the social-auth-app-django package are vulnerable to Authentication Bypass due to unintended email-based account association during the authentication pipeline. In social_django.storage.create_user (invoked by social_core.pipeline.user.create_user), an IntegrityError during user creation triggers a fallback that returns an existing User looked up by e-mail, effectively performing social_core.pipeline.social_auth.associate_by_email even when that step is disabled.

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

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 this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of control characters in column aliases within FilteredRelation. The FilteredRelation class fails to properly sanitize column aliases containing control characters when used with QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias() via dictionary expansion (**kwargs).

Affected versions of the Django package are vulnerable to SQL Injection due to improper sanitization of band index parameters in PostGIS raster lookups. The raster lookup functionality in Django's GIS module fails to properly validate or escape untrusted data used as a band index when performing spatial queries against PostGIS databases.

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

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. 
https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314

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

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.

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to quadratic time complexity during HTML parsing in text truncation methods. The django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True), as well as the truncatechars_html and truncatewords_html template filters, exhibit quadratic time complexity when processing inputs containing a large number of unmatched HTML end tags.

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/

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.

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

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

CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.

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 (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 the Django package are vulnerable to Information Disclosure (Timing Attack) due to non-constant-time comparison in the mod_wsgi authentication handler. The django.contrib.auth.handlers.modwsgi.check_password() function does not perform user existence checks in constant time, allowing response timing differences to reveal whether usernames exist.

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 fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

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.

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

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.

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.

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.

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

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

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

Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.

CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.

Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.

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

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.

Affected versions of this package are vulnerable to Time-of-Check Time-of-Use (TOCTOU) Race Condition. The file locking mechanism in SoftFileLock._acquire() performs permission validation before file creation without using the O_NOFOLLOW flag, leading to a race window where attackers with local access can create symlinks that redirect lock operations to arbitrary files. An attacker can exploit this vulnerability by creating a malicious symlink during the brief window between permission check and file creation, causing the lock to operate on unintended target files and potentially enabling unauthorized access or file corruption.

Affected versions of this package are vulnerable to a TOCTOU (Time-of-Check to Time-of-Use) symlink vulnerability due to improper handling of symlinks during lock file creation. The vulnerability exists because the package does not adequately check for symlink manipulation between the time the lock file path is checked and the time it is used. An attacker can exploit this vulnerability by creating a malicious symlink, potentially leading to unauthorized access or modification of files, which could compromise the integrity and security of the system.

Affected versions of the filelock package are vulnerable to a Time-of-Check Time-of-Use (TOCTOU) Race Condition due to a race window between a write-permission check and lock file creation that does not prevent symlink substitution. The flaw is in filelock.SoftFileLock in src/filelock/_soft.py, where _acquire() calls raise_on_not_writable_file() and then performs os.open() on the lock path, allowing the filesystem state to change between the check and the use.

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

Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts.

**Note:** This issue is due to an incomplete fix for CVE-2024-4340.

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.

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

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.

Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.

Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f

Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False.
This vulnerability is specific to Python's urllib3 library.

urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

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.

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

Affected versions of Requests, 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.

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.

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

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

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

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

Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.

Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.

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

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

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

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230719.txt

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

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 41.0.3  updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230714.txt

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

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

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

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

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

Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

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

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.

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

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

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

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix.
https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512

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 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 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 the social-auth-app-django package are vulnerable to Authentication Bypass due to unintended email-based account association during the authentication pipeline. In social_django.storage.create_user (invoked by social_core.pipeline.user.create_user), an IntegrityError during user creation triggers a fallback that returns an existing User looked up by e-mail, effectively performing social_core.pipeline.social_auth.associate_by_email even when that step is disabled.

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

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 this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of control characters in column aliases within FilteredRelation. The FilteredRelation class fails to properly sanitize column aliases containing control characters when used with QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias() via dictionary expansion (**kwargs).

Affected versions of the Django package are vulnerable to SQL Injection due to improper sanitization of band index parameters in PostGIS raster lookups. The raster lookup functionality in Django's GIS module fails to properly validate or escape untrusted data used as a band index when performing spatial queries against PostGIS databases.

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

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. 
https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314

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

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.

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to quadratic time complexity during HTML parsing in text truncation methods. The django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True), as well as the truncatechars_html and truncatewords_html template filters, exhibit quadratic time complexity when processing inputs containing a large number of unmatched HTML end tags.

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/

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.

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

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

CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.

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 (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 the Django package are vulnerable to Information Disclosure (Timing Attack) due to non-constant-time comparison in the mod_wsgi authentication handler. The django.contrib.auth.handlers.modwsgi.check_password() function does not perform user existence checks in constant time, allowing response timing differences to reveal whether usernames exist.

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 fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

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.

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

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.

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.

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.

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

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

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

Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.

CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.

Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.

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

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.

Affected versions of this package are vulnerable to Time-of-Check Time-of-Use (TOCTOU) Race Condition. The file locking mechanism in SoftFileLock._acquire() performs permission validation before file creation without using the O_NOFOLLOW flag, leading to a race window where attackers with local access can create symlinks that redirect lock operations to arbitrary files. An attacker can exploit this vulnerability by creating a malicious symlink during the brief window between permission check and file creation, causing the lock to operate on unintended target files and potentially enabling unauthorized access or file corruption.

Affected versions of this package are vulnerable to a TOCTOU (Time-of-Check to Time-of-Use) symlink vulnerability due to improper handling of symlinks during lock file creation. The vulnerability exists because the package does not adequately check for symlink manipulation between the time the lock file path is checked and the time it is used. An attacker can exploit this vulnerability by creating a malicious symlink, potentially leading to unauthorized access or modification of files, which could compromise the integrity and security of the system.

Affected versions of the filelock package are vulnerable to a Time-of-Check Time-of-Use (TOCTOU) Race Condition due to a race window between a write-permission check and lock file creation that does not prevent symlink substitution. The flaw is in filelock.SoftFileLock in src/filelock/_soft.py, where _acquire() calls raise_on_not_writable_file() and then performs os.open() on the lock path, allowing the filesystem state to change between the check and the use.

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

Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts.

**Note:** This issue is due to an incomplete fix for CVE-2024-4340.

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.

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

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.

Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.

Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f

Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False.
This vulnerability is specific to Python's urllib3 library.

urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

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

Affected versions of Requests, 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.

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.

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

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

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

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

Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.

Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.

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

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

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

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230719.txt

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

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 41.0.3  updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230714.txt

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

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

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

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

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

Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

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

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.

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

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

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

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix.
https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512

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 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 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 the social-auth-app-django package are vulnerable to Authentication Bypass due to unintended email-based account association during the authentication pipeline. In social_django.storage.create_user (invoked by social_core.pipeline.user.create_user), an IntegrityError during user creation triggers a fallback that returns an existing User looked up by e-mail, effectively performing social_core.pipeline.social_auth.associate_by_email even when that step is disabled.

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

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 this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of control characters in column aliases within FilteredRelation. The FilteredRelation class fails to properly sanitize column aliases containing control characters when used with QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias() via dictionary expansion (**kwargs).

Affected versions of the Django package are vulnerable to SQL Injection due to improper sanitization of band index parameters in PostGIS raster lookups. The raster lookup functionality in Django's GIS module fails to properly validate or escape untrusted data used as a band index when performing spatial queries against PostGIS databases.

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

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. 
https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314

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

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.

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to quadratic time complexity during HTML parsing in text truncation methods. The django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True), as well as the truncatechars_html and truncatewords_html template filters, exhibit quadratic time complexity when processing inputs containing a large number of unmatched HTML end tags.

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/

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.

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

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

CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.

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 (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 the Django package are vulnerable to Information Disclosure (Timing Attack) due to non-constant-time comparison in the mod_wsgi authentication handler. The django.contrib.auth.handlers.modwsgi.check_password() function does not perform user existence checks in constant time, allowing response timing differences to reveal whether usernames exist.

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 fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

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.

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

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.

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.

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.

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

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

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

Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.

CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.

Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.

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

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.

Affected versions of this package are vulnerable to Time-of-Check Time-of-Use (TOCTOU) Race Condition. The file locking mechanism in SoftFileLock._acquire() performs permission validation before file creation without using the O_NOFOLLOW flag, leading to a race window where attackers with local access can create symlinks that redirect lock operations to arbitrary files. An attacker can exploit this vulnerability by creating a malicious symlink during the brief window between permission check and file creation, causing the lock to operate on unintended target files and potentially enabling unauthorized access or file corruption.

Affected versions of this package are vulnerable to a TOCTOU (Time-of-Check to Time-of-Use) symlink vulnerability due to improper handling of symlinks during lock file creation. The vulnerability exists because the package does not adequately check for symlink manipulation between the time the lock file path is checked and the time it is used. An attacker can exploit this vulnerability by creating a malicious symlink, potentially leading to unauthorized access or modification of files, which could compromise the integrity and security of the system.

Affected versions of the filelock package are vulnerable to a Time-of-Check Time-of-Use (TOCTOU) Race Condition due to a race window between a write-permission check and lock file creation that does not prevent symlink substitution. The flaw is in filelock.SoftFileLock in src/filelock/_soft.py, where _acquire() calls raise_on_not_writable_file() and then performs os.open() on the lock path, allowing the filesystem state to change between the check and the use.

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

Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts.

**Note:** This issue is due to an incomplete fix for CVE-2024-4340.

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.

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

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.

Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.

Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f

Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False.
This vulnerability is specific to Python's urllib3 library.

urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

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.

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

Affected versions of Requests, 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.

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.

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

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

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

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

Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.

Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.

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

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

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

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230719.txt

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

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 41.0.3  updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230714.txt

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

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

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

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

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

Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

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

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.

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

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

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

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix.
https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512

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 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 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 the social-auth-app-django package are vulnerable to Authentication Bypass due to unintended email-based account association during the authentication pipeline. In social_django.storage.create_user (invoked by social_core.pipeline.user.create_user), an IntegrityError during user creation triggers a fallback that returns an existing User looked up by e-mail, effectively performing social_core.pipeline.social_auth.associate_by_email even when that step is disabled.

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

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 this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of control characters in column aliases within FilteredRelation. The FilteredRelation class fails to properly sanitize column aliases containing control characters when used with QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias() via dictionary expansion (**kwargs).

Affected versions of the Django package are vulnerable to SQL Injection due to improper sanitization of band index parameters in PostGIS raster lookups. The raster lookup functionality in Django's GIS module fails to properly validate or escape untrusted data used as a band index when performing spatial queries against PostGIS databases.

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

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. 
https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314

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

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.

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to quadratic time complexity during HTML parsing in text truncation methods. The django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True), as well as the truncatechars_html and truncatewords_html template filters, exhibit quadratic time complexity when processing inputs containing a large number of unmatched HTML end tags.

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/

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.

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

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

CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.

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 (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 the Django package are vulnerable to Information Disclosure (Timing Attack) due to non-constant-time comparison in the mod_wsgi authentication handler. The django.contrib.auth.handlers.modwsgi.check_password() function does not perform user existence checks in constant time, allowing response timing differences to reveal whether usernames exist.

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 fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

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.

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

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.

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.

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.

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

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

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

Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.

CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.

Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.

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

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.

Affected versions of this package are vulnerable to Time-of-Check Time-of-Use (TOCTOU) Race Condition. The file locking mechanism in SoftFileLock._acquire() performs permission validation before file creation without using the O_NOFOLLOW flag, leading to a race window where attackers with local access can create symlinks that redirect lock operations to arbitrary files. An attacker can exploit this vulnerability by creating a malicious symlink during the brief window between permission check and file creation, causing the lock to operate on unintended target files and potentially enabling unauthorized access or file corruption.

Affected versions of this package are vulnerable to a TOCTOU (Time-of-Check to Time-of-Use) symlink vulnerability due to improper handling of symlinks during lock file creation. The vulnerability exists because the package does not adequately check for symlink manipulation between the time the lock file path is checked and the time it is used. An attacker can exploit this vulnerability by creating a malicious symlink, potentially leading to unauthorized access or modification of files, which could compromise the integrity and security of the system.

Affected versions of the filelock package are vulnerable to a Time-of-Check Time-of-Use (TOCTOU) Race Condition due to a race window between a write-permission check and lock file creation that does not prevent symlink substitution. The flaw is in filelock.SoftFileLock in src/filelock/_soft.py, where _acquire() calls raise_on_not_writable_file() and then performs os.open() on the lock path, allowing the filesystem state to change between the check and the use.

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

Affected versions of the sqlparse package are vulnerable to Denial of Service (DoS) due to missing hard limits on token grouping recursion depth and token processing when formatting very large SQL tuple lists. During sqlparse.format() processing, the sqlparse.engine.grouping._group_matching() and sqlparse.engine.grouping._group() functions can recurse and iterate over excessively large tlist.tokens without enforcing MAX_GROUPING_DEPTH or MAX_GROUPING_TOKENS, allowing grouping work to grow until it effectively hangs.

Affected versions of this package are vulnerable to Denial of Service (DoS) attacks due to Algorithmic Complexity. The SQL parser fails to enforce limits when processing deeply nested tuples and large token sequences, leading to excessive resource consumption through crafted SQL statements with extreme nesting depth or token counts.

**Note:** This issue is due to an incomplete fix for CVE-2024-4340.

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.

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

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to improper handling of highly compressed HTTP response bodies during streaming decompression. The urllib3.HTTPResponse methods stream(), read(), read1(), read_chunked(), and readinto() may fully decompress a minimal but highly compressed payload based on the Content-Encoding header into an internal buffer instead of limiting the decompressed output to the requested chunk size, causing excessive CPU usage and massive memory allocation on the client side.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to allowing an unbounded number of content-encoding decompression steps for HTTP responses. The HTTPResponse content decoding pipeline in urllib3 follows the Content-Encoding header and applies each advertised compression algorithm in sequence without enforcing a maximum chain length or effective output size, so a malicious peer can send a response with a very long encoding chain that triggers excessive CPU use and massive memory allocation during decompression.

Urllib3's ProxyManager ensures that the Proxy-Authorization header is correctly directed only to configured proxies. However, when HTTP requests bypass urllib3's proxy support, there's a risk of inadvertently setting the Proxy-Authorization header, which remains ineffective without a forwarding or tunneling proxy. Urllib3 does not recognize this header as carrying authentication data, failing to remove it during cross-origin redirects. While this scenario is uncommon and poses low risk to most users, urllib3 now proactively removes the Proxy-Authorization header during cross-origin redirects as a precautionary measure. Users are advised to utilize urllib3's proxy support or disable automatic redirects to handle the Proxy-Authorization header securely. Despite these precautions, urllib3 defaults to stripping the header to safeguard users who may inadvertently misconfigure requests.

Urllib3 1.26.17 and 2.0.5 include a fix for CVE-2023-43804: Urllib3 doesn't treat the 'Cookie' HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a 'Cookie' header and unknowingly leak information via HTTP redirects to a different origin if that user doesn't disable redirects explicitly.
https://github.com/urllib3/urllib3/security/advisories/GHSA-v845-jxx5-vc9f

Affected versions of urllib3 are vulnerable to an HTTP redirect handling vulnerability that fails to remove the HTTP request body when a POST changes to a GET via 301, 302, or 303 responses. This flaw can expose sensitive request data if the origin service is compromised and redirects to a malicious endpoint, though exploitability is low when no sensitive data is used. The vulnerability affects automatic redirect behavior. It is fixed in versions 1.26.18 and 2.0.7; update or disable redirects using redirects=False.
This vulnerability is specific to Python's urllib3 library.

urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

Affected versions of the gunicorn package are vulnerable to HTTP Request/Response Smuggling due to improper validation of the Transfer-Encoding header that enables a TE.CL desynchronisation condition. Gunicorn’s HTTP parser does not consistently enforce RFC semantics when parsing conflicting or unsupported request framing—such as messages containing both Transfer-Encoding and Content-Length—so the backend may fall back to Content-Length while an intermediary treats the message as chunked.

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.

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.

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

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

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

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

Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.

Cryptography 39.0.1 includes a fix for CVE-2023-23931: In affected versions 'Cipher.update_into' would accept Python objects which implement the buffer protocol, but provide only immutable buffers. This would allow immutable objects (such as 'bytes') to be mutated, thus violating fundamental rules of Python and resulting in corrupted output. This issue has been present since 'update_into' was originally introduced in cryptography 1.8.

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

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

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

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230719.txt

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

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 41.0.3  updates its bundled OpenSSL version to include a fix for CVE-2023-2975: AES-SIV implementation ignores empty associated data entries.
https://github.com/pyca/cryptography/commit/bfa4d95f0f356f2d535efd5c775e0fb3efe90ef2
https://www.openssl.org/news/secadv/20230714.txt

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography 41.0.0 updates its dependency 'OpenSSL' to v3.1.1 to include a security fix.
https://github.com/pyca/cryptography/commit/8708245ccdeaff21d65eea68a4f8d2a7c5949a22

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

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

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

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

Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.

Cryptography 41.0.3 updates its bundled OpenSSL version to include a fix for a Denial of Service vulnerability.
https://github.com/pyca/cryptography/commit/b22271cf3c3dd8dc8978f8f4b00b5c7060b6538d
https://www.openssl.org/news/secadv/20230731.txt

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

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.

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

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

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

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

Cryptography 41.0.4 updates Windows, macOS, and Linux wheels to be compiled with OpenSSL 3.1.3, that includes a security fix.
https://github.com/pyca/cryptography/commit/fc11bce6930e591ce26a2317b31b9ce2b3e25512

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 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 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 the social-auth-app-django package are vulnerable to Authentication Bypass due to unintended email-based account association during the authentication pipeline. In social_django.storage.create_user (invoked by social_core.pipeline.user.create_user), an IntegrityError during user creation triggers a fallback that returns an existing User looked up by e-mail, effectively performing social_core.pipeline.social_auth.associate_by_email even when that step is disabled.

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

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 this package are vulnerable to Insufficient Verification of Data Authenticity. The library does not validate the `crit` (Critical) Header Parameter as required by RFC 7515 §4.1.11 — when a JWT contains a `crit` array listing extensions that the library does not understand, the token is accepted instead of rejected. An attacker can exploit this vulnerability by crafting JWTs with unknown critical extensions (e.g., MFA requirements, token binding, scope restrictions) that are silently ignored, potentially bypassing security policies or causing split-brain verification in mixed-library deployments where other RFC-compliant libraries would reject the same token.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of control characters in column aliases within FilteredRelation. The FilteredRelation class fails to properly sanitize column aliases containing control characters when used with QuerySet methods annotate(), aggregate(), extra(), values(), values_list(), and alias() via dictionary expansion (**kwargs).

Affected versions of the Django package are vulnerable to SQL Injection due to improper sanitization of band index parameters in PostGIS raster lookups. The raster lookup functionality in Django's GIS module fails to properly validate or escape untrusted data used as a band index when performing spatial queries against PostGIS databases.

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

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to inefficient string concatenation when processing duplicate HTTP headers in ASGI mode. The ASGIRequest class combines repeated headers using repeated string concatenation, resulting in super-linear (quadratic) time complexity when processing requests with many duplicate headers.

Affected versions of the Django package are vulnerable to SQL Injection due to improper handling of column aliases containing periods in QuerySet.order_by() when combined with FilteredRelation. The QuerySet.order_by() method fails to properly sanitize column aliases that contain periods when the same alias is used in FilteredRelation via dictionary expansion. 
https://github.com/django/django/commit/90f5b10784ba5bf369caed87640e2b4394ea3314

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

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.

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

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to quadratic time complexity during HTML parsing in text truncation methods. The django.utils.text.Truncator.chars() and Truncator.words() methods (with html=True), as well as the truncatechars_html and truncatewords_html template filters, exhibit quadratic time complexity when processing inputs containing a large number of unmatched HTML end tags.

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/

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.

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

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

CVE-2025-64458: Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to slow Unicode NFKC normalization on Windows being applied to untrusted inputs. The django.contrib.auth.views.LoginView and django.contrib.auth.views.LogoutView, and django.views.i18n.set_language normalize user-controlled strings using Python’s NFKC algorithm, which is unusually slow on Windows for huge Unicode sequences and can be triggered to consume excessive CPU.

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 (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 the Django package are vulnerable to Information Disclosure (Timing Attack) due to non-constant-time comparison in the mod_wsgi authentication handler. The django.contrib.auth.handlers.modwsgi.check_password() function does not perform user existence checks in constant time, allowing response timing differences to reveal whether usernames exist.

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 fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

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.

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

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.

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.

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.

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

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

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

Affected versions of the `django` package are vulnerable to Download of Code Without Integrity Check due to improper handling of user-supplied input in the HTTP FileResponse class. The vulnerability arises because the Content-Disposition header of a FileResponse can be set using a filename derived from user input without sufficient validation. An attacker can exploit this by crafting a request that causes a file with malicious content to be downloaded, potentially executing arbitrary code on the client system when the file is opened.

CVE-2025-64459: Affected versions of the Django package are vulnerable to SQL Injection due to improper input validation, allowing the internal _connector keyword argument to be accepted from untrusted dictionaries via expansion. The .filter(), .exclude(), and .get() methods on QuerySet, as well as the Q class, resolve **kwargs and will treat a supplied _connector value as the logical connector without constraining it to the expected set (AND/OR), permitting attacker-controlled tokens to influence SQL predicate construction.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient input sanitization in FilteredRelation column aliases. The FilteredRelation class fails to properly validate or escape column alias names when they are provided through dictionary expansion as keyword arguments to QuerySet.annotate() or QuerySet.alias() methods, allowing malicious SQL code to be injected directly into the generated database queries.

Django fixes potential SQL injection in ``FilteredRelation`` column aliases on PostgreSQL.

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

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.