Django 6.1.2 arrived on October 6, 2026, with fixes for four security issues and extra protection for GeoDjango. If your project runs Django 6.1, this is an update to apply soon. If you’re on Django 6.0 or 5.2, you can get the same security fixes with 6.0.9 or 5.2.18.
Two of the fixes are especially useful to understand if you work with the admin. One stops certain forms from being tricked into creating or deleting records they shouldn’t. Another fixes a problem when Django reads HTTP headers, the information sent along with a request. Because this can be reached without signing in, update Django first, then check the parts your project uses.
Django security release announcement Django’s announcement lists the affected versions, how serious each issue is, and the available fixes.
Which Django version should you install?
| Your current branch | Security patch |
|---|---|
| Django 6.1 | 6.1.2 |
| Django 6.0 | 6.0.9 |
| Django 5.2 LTS | 5.2.18 |
You can stay on the supported Django version you already use. If your project runs 5.2 LTS, for example, install 5.2.18 to get these fixes. You don’t need to move to 6.1 for this update.
There is one exception to keep in mind: Django 4.2 stopped receiving security updates in April 2026. If you still use it, you’ll need to move to a supported version. There won’t be a 4.2 patch for these issues.
Django downloads and supported versions Check the current patch and support status before updating.
What does Django 6.1.2 fix?
| Issue | Severity / status | What it affects |
|---|---|---|
| CVE-2026-77050 | Low | Very long language codes can use too much memory in the cache that remembers earlier lookups. |
| CVE-2026-84429 | Moderate | Certain quoted values in HTTP headers can take too long for Django to read. |
| CVE-2026-87890 | Moderate | Untrusted raster bytes in spatial lookups can make your server send unwanted requests. |
| CVE-2026-87975 | Moderate | Model formsets with editable primary keys can be tricked into creating or deleting records they shouldn’t. |
| CVE-2026-15830 follow-up | Hardening | Some binary geometry data with deeply nested shapes could get past the earlier depth limit. |
The header problem can be reached through Accept or Content-Type, two headers that describe the content a request accepts or sends. Someone doesn’t have to log in to reach it, so a login screen isn’t a reason to put off the update.
The language-code fix puts a limit on how long a code can be before Django looks it up in its cache. That helps stop unusually long codes from taking up too much memory.
Django 6.1.2 security details The release notes explain the fixes and changes to header parsing.
Check formsets with editable primary keys
A page that lets you edit several records at once may use what Django calls a model formset. The problem here was that someone could alter the submitted form data to delete records the page wasn’t allowed to manage. An edit-only formset, which should only change existing records, could also be tricked into creating a new one.
This affects forms that let the user set a record’s identifier, called its primary key. Examples include a UUID key included in the form, or a one-to-one relationship used as that key. Using UUIDs alone doesn’t make a form vulnerable: the key must be settable through the form. Models using Django’s default automatically assigned BigAutoField key were unaffected.
If your admin uses inline forms to edit related records, or pages that edit several records together, check whether they use these key types. After updating, make sure users can only create and delete the records they’re meant to manage.
Django formset security patch The official fix includes tests that check altered form submissions cannot bypass these limits.
GeoDjango users need an extra compatibility check
If your project uses GeoDjango to work with location or map data, give this part a closer look before deploying. Code that passes raw raster bytes, such as image-based map data, into spatial lookups may need changing. These lookups are queries about location or geometry.
Django now requires you to wrap those raster bytes in GDALRaster before using them in a lookup. This security change can break code that worked before the update. Bytes that represent valid geometry in hexadecimal form are still accepted.
You still need to check data that comes from uploads or other sources you don’t trust. Using GDALRaster meets the new requirement, but it doesn’t make that data safe. Validate it and check any references to external data sources before opening it.
Django spatial lookup security patch The official fix explains the change to how raster bytes are accepted in spatial lookups.
What should Vanta Admin users check?
If you use Vanta Admin, start by updating Django in your project. Your admin runs on that Django installation. If your project’s dependency file keeps Django on an older patch, updating the theme alone won’t give you these fixes.
There’s also a small admin fix worth checking if you use delete_confirmation_max_display. Setting it to zero should stop the admin from listing objects in inline error messages and on delete confirmation pages. Django 6.1.2 fixes a bug where those objects still appeared.
Once you’ve updated, spend a few minutes using your admin as your staff would. Sign in, open a record, edit related records in an inline form, and try deleting a record. Use the permissions your staff normally have. This helps you spot problems in any templates or admin behavior you’ve customized.
Django 6.1.2 admin bugfixes The release notes also cover the fixes to what the admin displays.
Update Django without broadening the upgrade
If you use uv and your project already runs Django 6.1, run the commands below from the folder containing pyproject.toml. Check that the Django version allowed in that file includes 6.1.2. If you’ve pinned it to an older exact version, change that value first.
uv lock --upgrade-package django==6.1.2
uv sync --locked
uv run --locked python -m django --version
If you use pip, activate your project’s virtual environment and run the commands below. Remember to update the dependency file or lockfile your build uses too. Otherwise, your next deployment could install the older version again.
python -m pip install --upgrade "Django==6.1.2"
python -m django --version
If your project runs Django 6.0 or 5.2, use 6.0.9 or 5.2.18 instead. Before committing, look through the changes to your dependency files. Updating Django may also need changes to packages it depends on.
uv documentation: upgrading locked packages You can choose an exact package version, as long as your project’s dependency settings allow it.
Verify the patch before and after deployment
Next, run your usual tests against your test database. If you use Django’s test runner, start with these commands from the folder containing manage.py:
python manage.py check
python -Wa manage.py test
If you use uv, put uv run --locked before each command. If your project uses pytest, run your usual pytest command instead. Django’s system checks help find problems in your settings; your application tests check that the project still behaves as expected.
- Check that your dependency file and lockfile use the security patch you intended to install.
- Run your application tests, including formsets, language handling, headers, and GIS features where your project uses them.
- Try admin login, editing, inline forms, and deletion with the permissions your staff normally have.
- Deploy the updated packages and restart the application processes.
- Check the Django version in the environment running your deployed application, then try its main user flows.
Once everything works locally, deploy the update and restart your application. That’s when your running site gets the fixes. Keeping this change small makes it easier to review, test, and get it live soon.
Django’s upgrade guide Read the release notes, run the full application test suite, then deploy the tested update.