What changed on 7 April

Link to this section

The Django project only maintains its current releases. Today those are 5.2 LTS (until April 2028), 6.0 (until April 2027) and 6.1 (until December 2027). For anything older, the security team's policy applies: those versions may be affected by a vulnerability, but that is neither investigated nor fixed.

Since 4.2 left support, Django has published 15 security vulnerabilities. They were fixed in 5.2, 6.0 and 6.1 only. Whether 4.2 is affected by any of them is something nobody checks any more.

Django security releases since the end of support for 4.2
ReleaseVulnerabilitiesSeverity
May 5, 20263all low
June 3, 20265all low
July 7, 20263all low
August 4, 202641 high (GeoDjango), 2 moderate (including XSS in the admin), 1 low

The count alone does not make Django less secure. According to the security team, many reports are now variants of known issues found with AI tools. What matters is that the fixes only reach supported versions.

The packages around Django have moved on as well. These no longer support 4.2 in their current releases:

  • Django REST framework from 3.18.0 (August 2026)
  • Wagtail from 7.4 (May 2026)
  • django CMS from 5.1 (July 2026)
  • django-debug-toolbar from 7.0 (June 2026)
  • django-filter from 25.2 (October 2025)

Platforms follow. Python 3.10, which many 4.2 projects run on, reaches its own end of life in October 2026. Heroku removes Python 3.10 on 6 January 2027, and AWS Lambda starts phasing out the runtime on 31 October 2026.

Self-check: how big is this for you?

Link to this section

You can ask your team or your hosting provider these seven questions without reading any code. Each answer moves the effort up or down.

  1. Which Django version runs in production? 4.2 is where this article starts. If it is older, 3.2 for example, the path gets longer.
  2. Which Python version? Django 5.2 needs Python 3.10 or newer. On 3.8 or 3.9, a Python upgrade comes first, and 3.10 itself ends in October 2026.
  3. Which database, in which version? Django 5.2 requires PostgreSQL 14 or newer. A database upgrade is a step of its own with its own risk.
  4. Are there automated tests, and do they run on every deploy? Tests show after every step that everything still works. Without them, every change is checked by hand.
  5. How many third-party packages are in the dependencies, and when were they last updated? What usually blocks an upgrade is not your own code but a package nobody maintains any more.
  6. When was the last deploy, and how does it work? A deploy that runs regularly and automatically is what makes an upgrade in small steps possible.
  7. Who still knows the code today? If the team has changed, the upgrade starts with an inventory.

Three ways forward

Link to this section

Upgrade to Django 5.2 LTS

The path the Django project itself recommends. 5.2 gets security updates until April 2028, and the packages around Django support it.

When it fits: Makes sense if the application is meant to run for years. For most, it is.

Paid extended support

Vendors such as HeroDevs or TuxCare keep shipping security patches for 4.2, priced on request. The code stays as it is. The packages around Django stay on their old versions, though, and the upgrade still comes later.

When it fits: Makes sense as a bridge when an upgrade is not possible in the coming months, during an audit or before a replacement, for example.

Stay and harden

Keep running with firewall rules, disabled features and close monitoring. Linux distributions such as Ubuntu keep patching their own Django package for a while, but that only helps if Django was installed through the operating system and not through pip.

When it fits: Makes sense only if the application is about to be switched off.

Why 5.2 and not 6.x straight away

Link to this section

Django 6.0 and 6.1 need Python 3.12 or newer. Django 5.2 runs on Python 3.10 to 3.14, so Django and Python can be upgraded separately. That is the safer path.

The next LTS release, 6.2, is due in April 2027 with updates until April 2030. From 2028, Django ships one release a year, each with three years of support. Moving to 5.2 on Python 3.12 or newer today keeps the next step open without time pressure.

What the effort depends on

Link to this section

There are no reliable published figures for the effort of a Django upgrade. It depends on a handful of factors that can be checked up front for each project:

  • Third-party packages. The most common blocker. Even python.org had to wait for a single package before it could move to 5.2.
  • Python. A jump from 3.8 or 3.9 often means a new base image or operating system as well.
  • Database. PostgreSQL below version 14 has to be upgraded first.
  • Tests. The better the coverage of the code the upgrade touches, the smaller the steps and the lower the risk.
  • Your own code. Between 4.2 and 5.2 a few things go away: time zones are the default, logout works by POST only, file storage is configured through STORAGES, index_together and old password hashers are removed. How often your code relies on them decides a good share of the hours.

An upgrade without downtime

Link to this section
  1. Inventory: record versions, packages, tests and the deployment before anything changes.
  2. Safety net: add tests where the upgrade touches the code.
  3. Packages: bring every package to a version that supports 5.2, or find a replacement.
  4. Step by step: 4.2, 5.0, 5.1, 5.2, with every warning fixed at each stage. Tools such as django-upgrade rewrite many changes automatically.
  5. Staging: check each step on an environment with production-like data.
  6. Rollout: each step goes live on its own, with a way back.