Hi all, > Thanks for the update, much appreciated. So yes this means we will > have to defer updates to the later point releases (window for uploads > is closing this weekend).
I finally have an update here locally, fixing 22 (!) CVEs in total. Three topics to raise at this point: 1. bookworm's Django is currently based on Django 3.2.19. However, we make some of the changes cleaner if we base this update on 3.2.25 instead, as this version includes 4 or 5 CVEs fixed without explicit Debian patches; changes that aren't the nicest to backport. Any objections to this version bump? Alas, upstream won't be releasing any more 3.2.x updates. 2. In #1126461, Moritz replied that they would prefer to fix Django in trixie via a DSA instead. Shall we do that for bookworm as well — i.e. not a pu after all? 3. My candidate version causes the same regression in the python-django-storages testsuite previously observed. As Steve pointed out, though "there are *already* changes in our version of django-storages that are clearly expected to work with the fixes in django. But they're not.". I am investigating this. 4. For completeness, my candidate version also causes some reverse-autopkgtest failures in django-fsm-admin, django-markupfield, django-webpack-loader and python-xapian-haystack (thanks, Debusine). However, these are not actually regressions; the testsuite already/always fails for these packages. This is mostly an FYI, but let me know if I need to do anything special for those. § My current/candidate changelog entry is as follows: Source: python-django Version: 3:3.2.25-1+deb12u1 Distribution: bookworm-security Urgency: high Maintainer: Chris Lamb <[email protected]> Timestamp: 1769541419 Date: Tue, 27 Jan 2026 11:16:59 -0800 Closes: 1051226 1099682 1113865 Changes: python-django (3:3.2.25-1+deb12u1) bookworm-security; urgency=high * Update to upstream's last 3.2 series release: - CVE-2023-41164: Potential denial of service vulnerability in django.utils.encoding.uri_to_iri(). This method was subject to potential denial of service attack via certain inputs with a very large number of Unicode characters. This fix was released in Django 3.2.21. (Closes: #1051226) - CVE-2023-43665: Address a denial-of-service possibility in django.utils.text.Truncator. Following the fix for CVE-2019-14232, the regular expressions used in the implementation of django.utils.text.Truncator’s chars() and words() methods (with html=True) were revised and improved. However, these regular expressions still exhibited linear backtracking complexity, so when given a very long, potentially malformed HTML input, the evaluation would still be slow, leading to a potential denial of service vulnerability. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus also vulnerable. The input processed by Truncator, when operating in HTML mode, has been limited to the first five million characters in order to avoid potential performance and memory issues. This fix was included in Django 3.2.22. - CVE-2024-24680: Potential denial-of-service in intcomma template filter. The intcomma template filter was subject to a potential denial-of-service attack when used with very long strings. This fix was included in Django 3.2.24. - CVE-2024-27351: Fix a potential regular expression denial-of-service (ReDoS) attack in django.utils.text.Truncator.words. This method (with html=True) and the truncatewords_html template filter were subject to a potential regular expression denial-of-service attack via a suitably crafted string. This is, in part, a follow up to CVE-2019-14232 and CVE-2023-43665, and was included in Django 3.2.25. * Drop debian/patches/CVE-2023-36053.patch now that we include the fix directly via 3.2.20. * CVE-2024-39329: Avoid a username enumeration vulnerability through timing difference for users with unusable password. The authenticate method of django.contrib.auth.backends.ModelBackend method allowed remote attackers to enumerate users via a timing attack involving login requests for users with unusable passwords. * CVE-2024-39330: Address a potential directory-traversal in django.core.files.storage.Storage.save. Derived classes of this method's base class which override generate_filename without replicating the file path validations existing in the parent class allowed for potential directory-traversal via certain inputs when calling save(). Built-in Storage sub-classes were not affected by this vulnerability. * CVE-2024-39614: Fix a potential denial-of-service in django.utils.translation.get_supported_language_variant. This method was subject to a potential DoS attack when used with very long strings containing specific characters. To mitigate this vulnerability, the language code provided to get_supported_language_variant is now parsed up to a maximum length of 500 characters. * CVE-2024-41989: Memory exhaustion in django.utils.numberformat. The floatformat template filter is subject to significant memory consumption when given a string representation of a number in scientific notation with a large exponent. * CVE-2024-41991: Potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget. The urlize and urlizetrunc template filters, and the AdminURLFieldWidget widget, are subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters. * CVE-2024-42005: Potential SQL injection in QuerySet.values() and values_list(). QuerySet.values() and values_list() methods on models with a JSONField are subject to SQL injection in column aliases via a crafted JSON object key as a passed *arg. * CVE-2024-45231: Potential user email enumeration via response status on password reset. Due to unhandled email sending failures, the django.contrib.auth.forms.PasswordResetForm class allowed remote attackers to enumerate user emails by issuing password reset requests and observing the outcomes. To mitigate this risk, exceptions occurring during password reset email sending are now handled and logged using the django.contrib.auth logger. * CVE-2024-53907: Potential DoS in django.utils.html.strip_tags. The strip_tags() method and striptags template filter were subject to a potential denial-of-service attack via certain inputs containing large sequences of nested incomplete HTML entities. * CVE-2024-56374: Potential denial-of-service vulnerability in IPv6 validation. A lack of upper bound limit enforcement in strings passed when performing IPv6 validation could have led to a potential denial-of-service (DoS) attack. The undocumented and private functions clean_ipv6_address and is_valid_ipv6_address were vulnerable, as was the GenericIPAddressField form field, which has now been updated to define a max_length of 39 characters. The GenericIPAddressField model field was not affected. * CVE-2025-13372: Fix a potential SQL injection attack in FilteredRelation column aliases when using PostgreSQL. FilteredRelation was subject to SQL injection in column aliases via a suitably crafted dictionary as the **kwargs passed to QuerySet.annotate() or QuerySet.alias(). * CVE-2025-26699: Address a potential denial-of-service in django.utils.text.wrap. The wrap() method and wordwrap template filter were subject to a potential denial-of-service attack when used with very long strings. (Closes: #1099682) * CVE-2025-32873: Denial-of-service possibility in strip_tags() django.utils.html.strip_tags() would be slow to evaluate certain inputs containing large sequences of incomplete HTML tags. This function is used to implement the striptags template filter, which was therefore also vulnerable. strip_tags() now raises a SuspiciousOperation exception if it encounters an unusually large number of unclosed opening tags. * CVE-2025-48432: Potential log injection via unescaped request path. Django's internal HTTP response logging used request.path directly, allowing control characters (e.g. newlines or ANSI escape sequences) to be written unescaped into logs. This could enable log injection or forgery, letting attackers manipulate log appearance or structure, especially in logs processed by external systems or viewed in terminals. Although this does not directly impact Django's security model, it poses risks when logs are consumed or interpreted by other tools. To fix this, the internal django.utils.log.log_response() function now escapes all positional formatting arguments using a safe encoding. * CVE-2025-57833: Potential SQL injection in FilteredRelation column aliases. The FilteredRelation feature in Django was subject to a potential SQL injection vulnerability in column aliases that was exploitable via suitably crafted dictionary with dictionary expansion as the **kwargs passed QuerySet.annotate() or QuerySet.alias(). (Closes: #1113865) * CVE-2025-59681: Potential SQL injection in QuerySet.annotate(), alias(), aggregate() and extra() on MySQL and MariaDB. QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate() and QuerySet.extra() methods were subject to SQL injection in column aliases, using a suitably crafted dictionary with dictionary expansion as the **kwargs passed to these methods on MySQL and MariaDB. * CVE-2025-59682: Potential partial directory-traversal via archive.extract(). The django.utils.archive.extract() function, used by startapp --template and startproject --template allowed partial directory-traversal via an archive with file paths sharing a common prefix with the target directory. * CVE-2025-64459: Prevent a potential SQL injection via _connector keyword argument in QuerySet/Q objects. The methods QuerySet.filter(), QuerySet.exclude(), and QuerySet.get() and the class Q() were subject to SQL injection when using a suitably crafted dictionary (with dictionary expansion) as the _connector argument. * CVE-2025-64460: Prevent a potential denial-of-service vulnerability in XML serializer text extraction. An algorithmic complexity issue in django.core.serializers.xml_serializer.getInnerText() allowed a remote attacker to cause a potential denial-of-service triggering CPU and memory exhaustion via a specially crafted XML input submitted to a service that invokes XML Deserializer. The vulnerability resulted from repeated string concatenation while recursively collecting text nodes, which produced superlinear computation. Regards, -- ,''`. : :' : Chris Lamb `. `'` [email protected] 🍥 chris-lamb.co.uk `-
