Django 5.1 released

The Django team is happy to announce the release of Django 5.1.

The release notes
showcase a kaleidoscope of improvements. A few highlights are:

Easier guardrails for authentication: the new and shiny LoginRequiredMiddleware,
when added to MIDDLEWARE, enforces authentication for all views by default.
A more inclusive framework: Django 5.1 includes several accessibility
enhancements, such as improved screen reader support in the admin
interface, more semantic HTML elements, and better association of help text
and labels with form fieldsets.
The second oldest ticket fixed in this release provides the long awaited
querystring template tag,
which greatly simplifies the handling of query strings when building URLs in
templates.

(If you are curious about the oldest ticket fixed in this release, check out Ticket #10743.)

You can get Django 5.1 from our downloads page or from the Python Package Index. The PGP key ID used for this
release is Natalia Bidart: 2EE82A8D9470983E.

With the release of Django 5.1, Django 5.0 has reached the end of mainstream
support. The final minor bug fix release, 5.0.8, was issued yesterday.
Django 5.0 will receive security and data loss fixes until April 2025. All
users are encouraged to upgrade before then to continue receiving fixes for
security issues.

See the downloads page for a table of
supported versions and the future release schedule.

Django security releases issued: 5.0.8 and 4.2.15

In accordance with our security release policy, the Django team
is issuing releases for
Django 5.0.8 and
Django 4.2.15.
These releases address the security issues detailed below. We encourage all
users of Django to upgrade as soon as possible.

CVE-2024-41989: Memory exhaustion in django.utils.numberformat.floatformat()

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.

Thanks to Elias Myllymäki for the report.

This issue has severity “moderate” according to the Django security policy.

CVE-2024-41990: Potential denial-of-service in django.utils.html.urlize()

The urlize() and urlizetrunc() template filters are subject to a potential
denial-of-service attack via very large inputs with a specific sequence of
characters.

Thanks to MProgrammer for the report.

This issue has severity “moderate” according to the Django security policy.

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.

Thanks to Seokchan Yoon for the report.

This issue has severity “moderate” according to the Django security policy.

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.

Thanks to Eyal Gabay of EyalSec for the report.

This issue has severity “high” according to the Django security policy.

Affected supported versions

Django main branch
Django 5.1 (currently at release candidate status)
Django 5.0
Django 4.2

Resolution

Patches to resolve the issue have been applied to Django’s
main, 5.1, 5.0, and 4.2 branches.
The patches may be obtained from the following changesets.

CVE-2024-41989: Memory exhaustion in django.utils.numberformat.floatformat()

On the main branch
On the 5.1 branch
On the 5.0 branch
On the 4.2 branch

CVE-2024-41990: Potential denial-of-service in django.utils.html.urlize()

On the main branch
On the 5.1 branch
On the 5.0 branch
On the 4.2 branch

CVE-2024-41991: Potential denial-of-service vulnerability in django.utils.html.urlize() and AdminURLFieldWidget

On the main branch
On the 5.1 branch
On the 5.0 branch
On the 4.2 branch

CVE-2024-42005: Potential SQL injection in QuerySet.values() and values_list()

On the main branch
On the 5.1 branch
On the 5.0 branch
On the 4.2 branch

The following releases have been issued

Django 5.0.8 (download Django 5.0.8 |
5.0.8 checksums)
Django 4.2.15 (download Django 4.2.15 |
4.2.15 checksums)

The PGP key ID used for this release is Sarah Boyce: 3955B19851EA96EF

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email
to [email protected], and not via Django’s Trac instance, nor via
the Django Forum, nor via the django-developers list. Please see our security
policies for further information.

Django 5.1 release candidate 1 released

Django 5.1 release candidate 1 is the final opportunity for you to
try out a kaleidoscope of improvements before Django 5.1 is released.

The release candidate stage marks the string freeze and the call for
translators to submit translations.
Provided no major bugs are discovered that can’t be solved in the next two
weeks, Django 5.1 will be released on or around August 7.
Any delays will be communicated on the on the Django forum.

Please use this opportunity to help find and fix bugs (which should be reported
to the issue tracker), you can
grab a copy of the release candidate package from our downloads page or on PyPI.

The PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E

Django security releases issued: 5.0.7 and 4.2.14

In accordance with our security release policy, the Django team
is issuing releases for
Django 5.0.7 and
Django 4.2.14.
These releases address the security issues detailed below. We encourage all
users of Django to upgrade as soon as possible.

CVE-2024-38875: Potential denial-of-service in django.utils.html.urlize()

urlize() and urlizetrunc() were subject to a potential denial-of-service
attack via certain inputs with a very large number of brackets.

Thanks to Elias Myllymäki for the report.

This issue has severity “moderate” according to the Django security policy.

CVE-2024-39329: Username enumeration through timing difference for users with unusable passwords

The django.contrib.auth.backends.ModelBackend.authenticate() method
allowed remote attackers to enumerate users via a timing attack involving login
requests for users with unusable passwords.

This issue has severity “low” according to the Django security policy.

CVE-2024-39330: Potential directory-traversal in django.core.files.storage.Storage.save()

Derived classes of the django.core.files.storage.Storage 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.

Thanks to Josh Schneier for the report.

This issue has severity “low” according to the Django security policy.

CVE-2024-39614: Potential denial-of-service in django.utils.translation.get_supported_language_variant()

get_supported_language_variant() was subject to a potential denial-of-service
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.

Thanks to MProgrammer for the report.

This issue has severity “moderate” according to the Django security policy.

Affected supported versions

Django main branch
Django 5.1 (currently at beta status)
Django 5.0
Django 4.2

Resolution

Patches to resolve the issue have been applied to Django’s main, 5.1, 5.0, and
4.2 branches. The patches may be obtained from the following changesets.

CVE-2024-38875: Potential denial-of-service in django.utils.html.urlize()

On the main branch
On the 5.1 branch
On the 5.0 branch
On the 4.2 branch

CVE-2024-39329: Username enumeration through timing difference for users with unusable passwords

On the main branch
On the 5.1 branch
On the 5.0 branch
On the 4.2 branch

CVE-2024-39330: Potential directory-traversal in django.core.files.storage.Storage.save()

On the main branch
On the 5.1 branch
On the 5.0 branch
On the 4.2 branch

CVE-2024-39614: Potential denial-of-service in django.utils.translation.get_supported_language_variant()

On the main branch
On the 5.1 branch
On the 5.0 branch
On the 4.2 branch

The following releases have been issued

Django 5.0.7 (download Django 5.0.7 |
5.0.7 checksums)
Django 4.2.14 (download Django 4.2.14 |
4.2.14 checksums)

The PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email
to [email protected], and not via Django’s Trac instance, nor via
the Django Forum, nor via the django-developers list. Please see our security
policies for further information.

Django 5.1 beta 1 released

Django 5.1 beta 1 is now available. It represents the second stage in the 5.1
release cycle and is an opportunity for you to try out the changes coming in
Django 5.1.

Django 5.1 brings a kaleidoscope of improvements which you can read about in
the in-development 5.1 release notes.

Only bugs in new features and regressions from earlier versions of Django will
be fixed between now and the 5.1 final release. Translations will be updated
following the “string freeze”, which occurs when the release candidate is
issued. The current release schedule calls for a
release candidate in a month from now, and a final release to follow about two
weeks after that, scheduled for August 7th.

Early and frequent testing from the community will help minimize the number of
bugs in the release. Updates on the release schedule are available on the
Django forum.

As with all alpha and beta packages, this is not for production use. But if
you’d like to take some of the new features for a spin, or to help find and fix
bugs (which should be reported to the issue tracker), you can grab a copy of the beta
package from our downloads page or
on PyPI.

The PGP key ID used for this release is Natalia Bidart: 2EE82A8D9470983E.

PyCharm & Django Campaign 2024

The Django Software Foundation’s biggest fundraising event of the year is here!

Get 30% off PyCharm, Support Django

Each year, our friends at JetBrains, the creators of PyCharm, run an incredible deal. You get a 30% discounted year of PyCharm, AND the DSF gets 100% of the money. Yes, 100%! It’s making a donation and directly getting a great product in return!

The fundraiser will be split this year, and the first half runs until June 15th! Buy PyCharm and support Django!

In the past, JetBrains through the PyCharm fundraiser has provided approximately one quarter of the Django Software Foundation’s budget! 

Donations like this fundraiser allow the DSF to function. Our two wonderful Fellows, Natalia Bidart and Sarah Boyce keep Django running smoothly, picking up pieces that would otherwise not happen.

The other side of the DSF is our support for Django groups across the globe. We supported every DjangoCon, particularly with donating funding towards opportunity grants for more people to be able to attend these conferences. The DSF also supports smaller events around the world, including DjangoGirls events.

Finally, I want to tell you about PyCharm itself.

PyCharm is an integrated development environment (IDE) that helps professional Python web developers be more productive, be more confident, and write better code. It supports the full Python web workflow out of the box, including popular Python web frameworks, such as Django, frontend technologies, and databases.

Here are the main benefits of using PyCharm in your Django development:

The built-in Django run/debug configuration type makes it easy to configure and start the Django server.
First-in-class code assistance for Django and Django templates, including navigation between views and templates, the ability to debug templates visually.
Code assistance for the Django REST Framework.
Refactoring and navigation for endpoints across your project in the Endpoints tool window.
Built-in HTTP Client.
Database integration, including PostgreSQL, SQLite, Redis and more!
Support for your frontend stack: JavaScript, React, Node.js, Tailwind CSS, and more.

Get Django work done with PyCharm, a powerful IDE tailored for Django web development!

Consider this the easiest charitable donation you will ever make, when you get such a great product in return!

Get 30% off PyCharm, Support Django

Other ways to donate

If you would like to donate in another way, especially if you are already a PyCharm customer, here are other ways to donate to the DSF:

On our website via credit card
Via GitHub Sponsors
For those able to make a larger donation, particularly corporate sponsors ($2000+), more information is here: Corporate membership

Thank you,

Catherine Holmes

DSF Assistant

Django Enhancement Proposal 14: Background Workers

As of today, DEP-14 has been approved 🛫

The DEP was written and stewarded by Jake Howard. A very enthusiastic community has been active with feedback and encouragement, while the Django Steering Council gave the final inputs before its formal acceptance. The implementation of DEP-14 is expected to be a major leap forward for the “batteries included” philosophy of Django.

Whilst Django is a web framework, there’s more to web applications than just the request-response lifecycle. Sending emails, communicating with external services or running complex actions should all be done outside the request-response cycle.

Django doesn’t have a first-party solution for long-running tasks, however the ecosystem is filled with incredibly popular frameworks, all of which interact with Django in slightly different ways. Other frameworks such as Laravel have background workers built-in, allowing them to push tasks into the background to be processed at a later date, without requiring the end user to wait for them to occur.

Library maintainers must implement support for any possible task backend separately, should they wish to offload functionality to the background. This includes smaller libraries, but also larger meta-frameworks with their own package ecosystem such as Wagtail.

This proposal sets out to provide an interface and base implementation for long-running background tasks in Django.

Read the full DEP-14 text
Pull Request review

Future work

The DEP will now move on to the Implementation phase before being merged into Django itself.

If you would like to help or try it out, go have a look at django-tasks, a separate reference implementation by Jake Howard, the author of the DEP.

Jake will also be speaking about the DEP in his talk at DjangoCon Europe at DjangoCon Europe 2024 in Vigo next week.