Django fixes six security flaws: update to 6.1.3, 6.0.10 or 5.2.19
Django's 3 November security releases fix six issues, one rated moderate, touching file uploads, page caching, the admin and GeoDjango. Here is what changed and what to do.
On this page
The Django project released Django 6.1.3, 6.0.10 and 5.2.19 on 3 November 2026. Together they fix six security issues. The project rates one of them moderate and the other five low, and asks everyone running Django to upgrade as soon as possible.
If a client site, an internal tool or an API you look after runs on Django, this is a routine but worthwhile update. Most of the fixes sit in specialised parts of the framework, but two affect common features: file uploads and page caching.
What was fixed
Server-side request forgery through GeoJSON (CVE-2026-111362, moderate). GeoJSON geometry can carry a crs member that points to a coordinate reference system by URL. The GDAL library resolves those URLs, so a crafted geometry could make the Django process send network requests or read files. Spatial lookups, the GeometryField form field and GEOSGeometry now refuse GeoJSON with an external CRS reference. DataSource and LayerMapping still accept them, because they are meant for trusted data.
Memory exhaustion in file uploads (CVE-2026-108147, low). A multipart upload sent with base64 Content-Transfer-Encoding could be held entirely in memory, ignoring the FILE_UPLOAD_MAX_MEMORY_SIZE setting, before it reached the upload handlers. Any site that accepts uploads uses this parser.
Private data and the cache (CVE-2026-113593, low). With UpdateCacheMiddleware or cache_page(), a request that left out a header named in Vary and a request that sent the same header empty produced the same cache key. That could serve a cached response to the wrong person. Cache keys now treat a missing header and an empty one as different values. After you upgrade, some cached responses will simply be built again on the next request.
Password hashes in the admin (CVE-2026-113733, low). Admin users with view-only permission could see a full password hash for some custom user setups: when the model was not AUTH_USER_MODEL, or when AUTH_USER_MODEL inherited its password field from a concrete parent through multi-table inheritance. This one is fixed for the 6.1 and 6.0 series; it is not listed in the 5.2.19 release notes.
Server-side request forgery through SpatialReference (CVE-2026-114582, low). String input to SpatialReference, and to the transform methods and srs setters built on it, was passed to GDAL, which by default resolves URLs and reads files. On GDAL 3.9 and later, Django now turns off that network and file access when it parses strings. DICT: references are rejected on every GDAL version.
Log injection through geometry forms (CVE-2026-111211, low). Invalid values submitted to geometry form fields were written to logs without escaping, so newlines or terminal escape codes could forge or distort log entries.
Which versions are supported
Django's download page lists three supported series:
- 6.1, now at 6.1.3, supported until December 2027.
- 6.0, now at 6.0.10, on security fixes only until April 2027.
- 5.2 LTS, now at 5.2.19, on security fixes only until April 2028.
A site on any older series gets none of these fixes. The project lists 6.2, the next long-term support release, for April 2027.
A note on GDAL
Full protection against CVE-2026-114582 needs GDAL 3.9 or later. Django adds a system check, gis.W001, that warns when the installed GDAL is older. If you cannot upgrade GDAL yet, the project recommends integer SRIDs, which are looked up directly in the EPSG database, and checking any string input against an allow list.
What it means for your site
- Find your Django sites. Check the installed version in each project's requirements or lock file, then move to 6.1.3, 6.0.10 or 5.2.19, whichever matches the series you are on.
- Upgrade now if you accept uploads or use the cache framework. Those are the two fixes most sites touch.
- Treat GeoDjango as the priority. If a site takes GeoJSON or spatial reference strings from users, it carries the moderate-rated issue. Upgrade Django and check your GDAL version.
- Check custom user models on 5.2. If you run 5.2 with a custom user setup and give staff view-only admin access, read the release notes for your version, since the admin password-hash fix is listed for 6.1 and 6.0.
- Plan off unsupported series. If a client site still runs a Django series that is out of support, an upgrade is the only way to receive security fixes like these.
- Expect a cache refill. After the upgrade, some cached pages are rebuilt on first request. No other action is needed.
