- Django issued 6.1.2, 6.0.9 and 5.2.18 on October 6 to fix four vulnerabilities: one rated low and three rated moderate.
- Two of the fixes only matter for apps built in particular ways, and two change behaviour that existing code may rely on.
- Teams should upgrade, then check their use of GIS spatial lookups, formset primary keys and any direct header-parsing calls.
The second question after "have you patched?"
Most security advisories ask one thing. Are you on the fixed version? Django's October release asks a second question. How did your team build the application?
The Django project published releases 6.1.2, 6.0.9 and 5.2.18 on October 6. The team urges every user to move to a fixed version soon.
The lesson here is simple. For some of these flaws, the version number does not tell you whether you were exposed. Your own design choices do.
What the releases fix
Django fixed four issues. One is rated low under the project's security policy. Three are rated moderate.
The fixes went into the main development branch and into three release lines: 6.1, 6.0 and 5.2.
CVE-2026-77050 is a denial-of-service risk in get_supported_language_variant(). CVE-2026-84429 is a denial-of-service risk in HTTP header parsing. CVE-2026-87890 is request forgery through spatial lookups. CVE-2026-87975 is privilege abuse in model formsets.
How the header flaw works
This flaw reaches the widest audience. The function django.utils.http.parse_header_parameters() reads structured values in request headers, such as Accept and Content-Type.
Django found that it slowed sharply when a quoted value held many separators. The time taken grew with the square of the input size.
In plain terms, doubling the input roughly quadruples the work. A crafted header can keep a server process busy far longer than its size suggests.
Django says an unauthenticated request could reach this code. One route is the content negotiation done by HttpRequest.accepts().
Django also points to a gap in the safeguards. A length cap applies to each call. An attacker can repeat the header many times, and the total can still grow large.
No login is needed to trigger it. That is why a moderate rating still calls for a prompt upgrade.
The fix has a side effect. Django moved the function onto Python's email.message.Message parser. Some odd or malformed header values may now be read differently.
One case: a value in the RFC 2231 style that lacks an encoding label is now decoded. The function is undocumented. Any code that calls it directly should be tested.
That limit answers the low-severity issue. Django caches results by language code, and the code's length was not checked first. An attacker sending many different, very long codes could fill the process's memory.
Where your own choices decide exposure
The other two flaws apply only to certain designs. The first involves geographic features. Spatial lookups accepted raster data as plain bytes, with no wrapper to mark them as trusted.
Those bytes could contain a VRT document that points to an outside raster source. The GDAL library could then make network requests as the Django process user.
Django says apps were exploitable if they passed attacker-controlled bytes straight into a spatial lookup. It adds that an earlier fix, for CVE-2026-15307, missed this case. Two fixes in one area show that patches need review too.
The new fix breaks compatibility. Raster bytes must now be wrapped in GDALRaster. Bytes that represent valid hexadecimal geometries still work.
Django's reminder is to check any input from users before using it.
The formset flaw depends on primary keys. Forged POST data could delete records outside the limiting queryset. It could also create records through edit-only formsets.
The attack worked only where the form let users supply the primary key. Django lists a OneToOneField, a parent link used as a primary key, and a natural or UUID key included in the form's fields.
Models with Django's default key, BigAutoField, were not affected. A schema decision made years ago now decides whether this bug applies to you.
Context, with limits
WebPulse holds a CVE profile for Django, matched from NIST NVD data and refreshed October 6. It lists 157 CVEs in total. Of those, 32 were published in the last 12 months. None appear in CISA's Known Exploited Vulnerabilities catalog.
Read that count as a record of disclosure, not a score. It shows how often the project reports and fixes issues. It does not rank Django against any other framework.
Questions for your team
Ask which Django line each application runs. Ask when each will move to 6.1.2, 6.0.9 or 5.2.18.
Ask whether any code calls parse_header_parameters() directly. If so, test it with unusual header values.
Ask whether any application uses django.contrib.gis. Ask whether user-supplied bytes ever reach a spatial lookup.
Ask which formsets use OneToOneField, UUID or natural primary keys. Those teams should review them with the patch in hand.
Also ask who owns this check. Patching is routine. Knowing which fixes touch which applications takes an inventory of how each one was built.
A version number tells you what the code can do. Only your own design tells you what it will be asked to do.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Django.
