Django security releases issued: 6.1.3, 6.0.10, and 5.2.19

The Django team issued official security updates on Nov. 3, 2026, delivering versions 6.1.3, 6.0.10, and 5.2.19 alongside fixes across its main development branch. As detailed in Django Weblog's report, the maintenance release addresses six distinct vulnerabilities spanning server-side request forgery, memory exhaustion, log injection, cache collision, and credential leakage in the administrative interface. The patches close functional exposure in core file upload parsers, HTTP caching middleware, and the GIS geographic query toolset used across production deployments.

This breakdown covers the six resolved security advisories, the operational mechanics of each vulnerability, and the migration requirements for engineering teams maintaining Python web services. Engineering leads, infrastructure operators, and backend developers maintaining applications on Django 5.2, 6.0, 6.1, or tracking the development trunk will find the specific package update targets, GDAL library version dependencies, and system check warnings introduced across these builds.

What Django security shipped

The core update resolves six tracked vulnerabilities spanning five low-severity defects and one moderate-severity flaw. The most significant finding, tracked as CVE-2026-111362 with moderate severity, eliminates a server-side request forgery vector where earlier GeoJSON specifications permitted coordinate reference system definitions via remote URLs. Because GDAL automatically resolved those endpoints, user-supplied geometries allowed unauthorized outbound requests or local file reads executed as the Django process user. In the core framework, CVE-2026-108147 patches a memory exhaustion vector in MultiPartParser where base64-encoded multipart uploads were buffered fully into memory regardless of FILE_UPLOAD_MAX_MEMORY_SIZE limits.

Further fixes address administrative visibility and caching boundaries across standard request pipelines. Under CVE-2026-113733, the Django admin interface leaked raw password hashes to users possessing only view permissions whenever inspecting custom models outside AUTH_USER_MODEL or user models utilizing multi-table inheritance. Middleware caching rules received structural corrections under CVE-2026-113593, ensuring UpdateCacheMiddleware and cache_page() no longer assign identical cache keys to omitted versus empty HTTP headers listed in a response Vary header. Two additional GIS defects, CVE-2026-111211 and CVE-2026-114582, resolve unescaped terminal control character logging in GeometryField forms and untrusted string resolution inside SpatialReference handlers.

What changed for builders in Django security

Builders using GeoJSON inputs and caching middleware gain strict input sanitization boundaries alongside standardized RFC compliance. Geometry field lookups, GeometryField form processing, and GEOSGeometry constructors now actively reject incoming GeoJSON payloads carrying coordinate reference system references to external resources, while internal data loading tools like DataSource and LayerMapping retain support for trusted data streams. In the HTTP caching layer, cache key generation now strictly differentiates between missing and empty request headers according to RFC 9111 section 4.1 specifications, immediately invalidating legacy collision-prone cache entries across active instances.

The spatial reference toolset modifies behavior across multiple geometric transformation APIs to block unintended system traversal. Passing untrusted strings to SpatialReference, GEOSGeometry.transform(), OGRGeometry.transform(), GDALRaster.transform(), the srs setter of OGRGeometry, or the srs and srid setters of GDALRaster no longer triggers network requests or local filesystem reads on modern environments. Dictionary lookups prefixed with DICT: or ESRI:: are uniformly rejected across every supported version, shutting down chained probing attacks that targeted local system assets.

How to install or upgrade Django security

Engineering teams must update their environment dependencies to the patched point releases corresponding to their deployed series. Projects running the 6.1 branch require Django 6.1.3, deployments on 6.0 need Django 6.0.10, and long-term environments on 5.2 must pull Django 5.2.19. Official tarballs and checksum signatures are published under PGP key ID 131403F4D16D8DC7 registered to release manager Jacob Walls.

Upgrades can be applied directly using standard Python package management tooling:

pip install --upgrade "Django>=6.1.3,<6.2"

For applications pinned to the 6.0 or 5.2 release lines, specify the targeted maintenance version explicitly:

pip install --upgrade "Django>=6.0.10,<6.1"

To update an environment pinned to the older long-term support release branch:

pip install --upgrade "Django>=5.2.19,<5.3"

After installing the updated library files, verify that the active runtime reports the corrected patch revision:

python -m django --version

Gotchas and compatibility in Django security

The most critical operational gotcha affects teams using django.contrib.gis with older versions of the underlying C geospatial library. Full protection against server-side request forgery via SpatialReference string parsing under CVE-2026-114582 requires GDAL 3.9 or higher. On legacy host environments running GDAL versions prior to 3.9, the framework cannot programmatically disable network and file access within the C library, leaving instances partially exposed unless incoming spatial inputs are restricted to integer SRIDs verified against the EPSG database or validated against a rigid internal allow list.

Teams upgrading systems with spatial capabilities will encounter a newly added system check, gis.W001, which triggers an automated warning whenever the host system executes on GDAL versions below 3.9. Additionally, applications relying on UpdateCacheMiddleware or the cache_page() decorator will experience a minor influx of backend cache misses immediately following deployment. Because the new key generation scheme strictly isolates omitted headers from empty headers per RFC 9111, previously stored cache records omitting headers designated in Vary directives will not match incoming requests and will naturally repopulate on subsequent hits.

What to watch after Django security

Following deployment, system administrators should inspect application logs and monitoring telemetry for rejected spatial coordinate lookups or malformed geometry form posts. Legitimate integrations importing spatial data through user-facing endpoints will break if they rely on external coordinate reference system URLs or string paths inside SpatialReference calls. Any workflows requiring the ingestion of trusted remote datasets must be transitioned to DataSource or LayerMapping classes, which explicitly retain permission to process external coordinate resources.

Development groups operating custom user authentication models must audit admin group permissions to confirm that view-only staff profiles retain expected interface access without operational disruptions. For vulnerability management, the Django security team reminds engineers that zero-day discoveries and vulnerability notifications must be submitted directly via encrypted email to security@djangoproject.com rather than submitted to public Trac tickets or posted on the Django Forum.