Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

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 the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

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 the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

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 the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.

Affected versions of the Django package are vulnerable to Denial of Service due to unbounded request-body allocation when reading HttpRequest.body for ASGI requests whose Content-Length header is missing or understates the actual payload size. The body-reading path relies on the declared Content-Length to enforce the DATA_UPLOAD_MAX_MEMORY_SIZE cap, so an ASGI request that omits Content-Length or advertises a smaller value than the payload being streamed bypasses the limit check and reads the full incoming body into memory. An unauthenticated remote attacker can exploit this against a Django application served over ASGI by sending a request without Content-Length or with an understated value, causing the server to load an arbitrarily large request body into memory and exhaust available resources on the host.

Affected versions of the Django package are vulnerable to Missing Authorization due to the admin changelist view processing forged POST data against a ModelAdmin that defines list_editable without enforcing that submitted rows correspond only to existing records a user is permitted to edit. The changelist form handling is under ModelAdmin.list_editable accepts form entries whose primary key values do not match any existing row and creates new instances from them, treating the inline edit endpoint as an implicit create path that bypasses the add-permission check. An authenticated admin user who holds change permission on a model exposed via list_editable but lacks add permission can exploit this by submitting crafted POST data to the changelist endpoint to create new instances of that model, resulting in unauthorized record creation within the Django admin.

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 Path Traversal due to improper validation of archive member paths during extraction. The django.utils.archive.extract() function—used by the startapp --template and startproject --template commands—checked path prefixes instead of using canonicalised paths, allowing archive entries whose names share a prefix with the destination to resolve outside the intended directory.

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.

Django fixes a potential denial-of-service vulnerability in XML ``Deserializer``.

Affected versions of the Django package are vulnerable to Denial of Service due to inefficient algorithmic complexity in MultiPartParser when handling multipart upload parts that declare Content-Transfer-Encoding: base64 and include excessive whitespace. The parser normalises and decodes the base64 body of each part without bounding the volume of interstitial whitespace, so processing time grows disproportionately with the amount of attacker-supplied whitespace embedded in the encoded payload, reaching a pathological worst case under crafted input. An authenticated remote attacker able to submit multipart uploads can exploit this by including large amounts of whitespace inside a base64-encoded part to consume excessive CPU during request parsing, degrading availability of the Django application.

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

Affected versions of the Django package are vulnerable to HTTP Header Spoofing due to ambiguous normalisation of request header names in ASGIRequest, where two distinct on-the-wire header variants that differ only in underscore versus hyphen separators collapse to the same internal key. When Django builds the request META mapping for an ASGI request, a header such as X-Forwarded-For and a client-supplied X_Forwarded_For are both mapped to the single underscore form, so an attacker-controlled header can overwrite or masquerade as a trusted header set by a fronting proxy or middleware. An unauthenticated remote attacker can exploit this by sending an HTTP request containing an underscore-separated header name that collides with a trusted hyphenated header to spoof values relied on by downstream middleware or application code, such as forwarded-client or authentication-related headers, leading to authentication bypass and integrity impact.

Affected versions of the Django package are vulnerable to Missing Authorization due to GenericInlineModelAdmin failing to validate add permissions on inline model instances when processing forged POST data on admin change forms. When the admin changes view handles inline formsets backed by GenericInlineModelAdmin, new inline rows submitted in the POST payload are persisted without verifying that the requesting user holds add permission on the target inline model, so the add-permission check is effectively skipped for generic inline relationships. An authenticated admin user who holds change permission on a parent model but lacks add permission on an associated generic-inline model can exploit this by submitting crafted POST data containing additional inline rows, creating new instances of the inline model and resulting in unauthorised record creation within the Django admin.

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

Affected versions of the Django package are vulnerable to Denial of Service due to uncontrolled resource consumption during URL parsing on Windows. The URLField.to_python() method invokes urllib.parse.urlsplit(), which performs NFKC normalisation on Windows that is disproportionately slow for certain Unicode characters. A remote attacker can submit large URL inputs containing these characters to forms backed by URLField, causing excessive CPU consumption and rendering the service unavailable.

Affected versions of the Django package are vulnerable to SQL Injection due to insufficient neutralization of user-controlled column alias names provided via dictionary expansion. The QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() methods accept **kwargs whose keys are used as column aliases, and on MySQL and MariaDB, those identifiers are not safely quoted, permitting crafted input to be incorporated into the generated SQL.

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.

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.

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.

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

Affected versions of the Django package are vulnerable to Information Disclosure due to erroneous caching behaviour in the django.middleware.cache.UpdateCacheMiddleware component. The middleware incorrectly caches responses for requests where the Vary header contains an asterisk (*), which, per the HTTP specification, signals that the response should not be cached under any conditions, resulting in private user data being stored in the shared cache backend. An attacker who accesses a cached page can retrieve private response data that was intended only for the original authenticated user.

Affected versions of the Django package are vulnerable to Information Disclosure due to improper handling of response header variation when SESSION_SAVE_EVERY_REQUEST is set to True. When a session is not modified during a request cycle, Django's session middleware fails to include the Set-Cookie header in the Vary response header, causing caching intermediaries to store and serve responses that carry session cookies to subsequent users who request the same cached resource. A remote attacker who causes a victim user to visit a cached public page can steal the user's session cookie, enabling session hijacking.

Affected versions of the Django package are vulnerable to Denial of Service (DoS) due to improper enforcement of the FILE_UPLOAD_MAX_MEMORY_SIZE limit when processing ASGI requests with missing or understated Content-Length headers. The ASGI request handler does not correctly account for the discrepancy between the declared Content-Length value and the actual data volume received, allowing request bodies that exceed the configured memory limit to be buffered entirely in memory.

Affected versions of the urllib3 package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects in the low-level proxy API. When following cross-origin redirects via ProxyManager.connection_from_url().urlopen() with assert_same_host=False, sensitive headers including Authorization, Cookie, and Proxy-Authorization are not stripped, unlike the high-level API, which removes them via Retry.DEFAULT_REMOVE_HEADERS_ON_REDIRECT. An attacker controlling a redirect target can capture these sensitive headers from requests that follow cross-origin redirects through the low-level proxy API path.

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

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.