Django 6.1.2, 6.0.9 and 5.2.18: Mapping the October CVEs to Your Code

On 6 October 2026 the Django team issued security releases 6.1.2, 6.0.9 and 5.2.18. They fix four new CVEs, one rated low and three moderate under Django's own policy, plus a strengthened fix for a GeoDjango denial of service patched in an earlier release. Two days later the security team announced it no longer accepts new reports through HackerOne; reports now go to security@djangoproject.com.

Moderate is not a reason to wait, but it is a reason to read closely. Each of the four issues lives in a specific part of Django, and three of them only matter if your project uses that part.

What's affected

Supported branches 6.1, 6.0 and 5.2 are affected, along with main. Fixed releases are 6.1.2, 6.0.9 and 5.2.18. Django's announcement covers only supported versions, so anything older than 5.2 should be treated as unpatched.

CVE-2026-84429, moderate: HTTP header parsing DoS. django.utils.http.parse_header_parameters() had quadratic time complexity on a value with many separators inside a quoted parameter. The advisory says "an unauthenticated request could reach this parsing through headers such as Accept or Content-Type", for instance through the content negotiation in HttpRequest.accepts(), and that the per-call length limit does not bound the combined size of repeated headers. The function now uses Python's email.message.Message for parsing, so some unusual header values may parse differently.

CVE-2026-87975, moderate: model formsets with editable primary keys. Forged POST data could delete instances outside a formset's limiting queryset, or create instances through an edit-only formset, when the model's primary key can be set through the form. Examples given: a OneToOneField primary key, a parent link used as the primary key of an inline formset's model, or a natural or UUID primary key included in the form's fields. Models using the default BigAutoField primary key are not affected.

CVE-2026-87890, moderate: request forgery via spatial lookup bytes. GeoDjango spatial lookups accepted raw bytes as raster values. Those bytes could hold a GDAL VRT document pointing at an external source, making GDAL issue network requests as the Django process. Only apps passing attacker-controlled bytes directly to a spatial lookup are exposed. The fix is backward incompatible: raster bytes must now be wrapped in GDALRaster.

CVE-2026-77050, low: language code cache growth. get_supported_language_variant() cached very long language codes before limiting their length, so many distinct long codes could consume memory. Codes over 500 characters are now rejected or truncated first.

Follow-up to CVE-2026-15830. Certain WKB geometries could bypass the earlier mitigation for deeply nested geometry collections reaching GEOS. No new CVE.

How to check if you're exposed

Confirm the version in each environment, not just in the lockfile:

python -m django --version
pip show django | grep -i '^version'

Then check which features each CVE needs:

# CVE-2026-84429: assume yes for any internet-facing Django site

# CVE-2026-87975: formsets on models with settable primary keys
grep -rnE "modelformset_factory|inlineformset_factory|edit_only" --include=*.py .
grep -rnE "primary_key=True" --include=models.py .

# CVE-2026-87890 and the CVE-2026-15830 follow-up: GeoDjango
grep -rn "django.contrib.gis" --include=settings*.py .

# CVE-2026-77050: internationalization
grep -rnE "LocaleMiddleware|USE_I18N" --include=settings*.py .

For the formset issue, look at every model the formsets point to. If its primary key is a OneToOneField, a UUIDField exposed in the form, or any field users can type into, review that view. The bug is about forged POST data, so a formset reachable by low-privilege users is the priority.

For GeoDjango, search for spatial lookups that take request data. A lookup that receives bytes uploaded by a user, rather than geometry you built, is the reachable case.

What to do now

1. Upgrade to 6.1.2, 6.0.9 or 5.2.18. If you're on an older series, plan the move to 5.2 or later now; unsupported versions don't get these fixes.
2. Test header handling after upgrading. Because parse_header_parameters() now uses a different parser, run your API tests that send unusual Content-Type or Accept values.
3. Update GeoDjango code that passes raster bytes. Wrap them in GDALRaster yourself, after validating the source. Lookups that now fail are telling you where untrusted bytes were flowing.
4. Limit header size at the proxy. A cap on total header bytes in your load balancer or web server reduces the impact of header parsing bugs in any framework.
5. Update your reporting docs if they tell researchers to use Django's HackerOne program. New reports go to security@djangoproject.com.

Why it matters

Framework releases bundle unrelated fixes, and the moderate label hides how differently they land. The header parsing bug touches the code path every request takes. The GeoDjango bug touches a contrib app that most projects never install. Patch once, but triage separately, because the questions you ask afterwards are different. For the header bug: did anyone exploit it? For the formset bug: were any records deleted that shouldn't have been?

Try it yourself

Run the grep block above against one Django project and write a one-line verdict for each CVE: reachable, not reachable, or needs review. Then check your web server logs for requests with unusually long Accept or Content-Type headers in the weeks before you patched.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Django security releases issued: 6.1.2, 6.0.9, and 5.2.18
• Django security reporting update, 8 October 2026
• Django security policy
• Django on PyPI