Potheeswaran 
The Django development team has released versions 6.0.7 and 5.2.16, addressing three distinct security vulnerabilities that could expose sensitive user data, leak heap memory, or enable header injection attacks.
Announced by core developer Jacob Walls on July 7, 2026, the releases follow Django’s standard security disclosure policy and affect the framework’s main branch, the 6.1 beta, and both supported stable branches.
While all three vulnerabilities carry a “low” severity rating, cybersecurity teams managing Django deployments should not treat that classification as grounds for delaying patching. Low severity typically reflects difficulty in exploitation or a limited scope, not the absence of real risk.
Django 6.0.7 & 5.2.16 Released
The most operationally significant issue involves UpdateCacheMiddleware and the cache_page decorator. These caching tools are designed to skip storing responses that set cookies when the request varies on the Cookie header, but only if the incoming request carried no cookies whatsoever.
In practice, this assumption broke down easily. Any request arriving with an unrelated cookie, such as a language preference or theme setting, bypassed the protection entirely.
The result: responses that set session or authentication cookies could end up cached in Django’s shared cache layer, potentially serving one user’s session cookie to another. Researcher Chris Whyland reported the flaw.
The second vulnerability sits in Django’s GIS module, specifically django.contrib.gis.gdal.GDALRaster. When instantiated from a bytes object representing a raster file, the vsi_buffer property could read roughly 32 bytes beyond its allocated memory boundary.
This over-read is a classic memory-safety bug, capable of leaking adjacent heap memory or, in rare cases, triggering a segmentation fault.
The impact is limited to rasters stored in GDAL’s virtual filesystem, narrowing the practical attack surface, but organizations running geospatial applications on Django should verify their GIS dependencies. Bence Nagy is credited with the discovery.
The third issue affects django.core.validators.DomainNameValidator, which failed to reject newline characters in domain name input. If a developer used this validator outside a standard Django form field and then inserted the resulting value into an HTTP response, it could lead to header injection.
Django’s own HttpResponse class blocks newlines in headers, so the framework itself was never directly exploitable. The risk materializes specifically when developers use DomainNameValidator independently, since CharField normally strips newlines automatically. Bence Nagy also reported this vulnerability.
The vulnerabilities touch Django’s main development branch, the upcoming 6.1 beta, and the currently supported 6.0 and 5.2 series. The Django team has published individual patch commits for each branch and each CVE, allowing self-hosted deployments to backport fixes if immediate upgrades aren’t feasible.
Organizations should prioritize the cache middleware fix first, given its potential to expose cross-user data in production caching layers. Teams can verify authenticity using Jacob Walls’ PGP key before deploying downloaded tarballs.
- Upgrade to Django 6.0.7 or 5.2.16 immediately using pip or your dependency manager.
- Audit caching configurations for any views setting cookies alongside
Vary: Cookieheaders. - Review GIS-related code paths if your application processes raster files via GDAL.
- Check for standalone use of
DomainNameValidatoroutside form fields and sanitize inputs accordingly. - Verify tarball checksums and PGP signatures before deployment in production environments.
About the Author
