On 4 August 2026 the Django project issued security releases 6.0.8 and 5.2.17 for four CVEs. The headline is CVE-2026-15307, rated High: spatial lookups passed str and dict values to GDALRaster, which depending on the driver could write files to disk, possibly leading to code execution, or make network requests as the Django process user.
Three of the four CVEs need GeoDjango (django.contrib.gis). That is a clean reachability line: if your project does not use it, those bugs are not in your running code.
What's affected
Fixes landed in the main, 6.1 (then at release candidate), 6.0 and 5.2 branches, with packaged releases 6.0.8 and 5.2.17. The post lists no 6.1 final release.
- CVE-2026-15307 (High): spatial lookups accepting rasters as
strordict. Staff users with view permission on a model with a spatial field could reach it through the admin changelist filter. The fix rejectsdictvalues andstrvalues that are not validGEOSGeometryinput, which is backward incompatible for lookups. Model field assignment is unchanged. - CVE-2026-15830 (Moderate): deeply nested
GEOMETRYCOLLECTIONinput can crash GEOS with a segmentation fault (CVE-2026-15830). WKT is now limited to nesting depth 198, with a newmax_geom_collectionsargument. - CVE-2026-15920 (Moderate): the admin rendered
URLFieldvalues as links without checking the scheme, so a stored dangerous scheme could become a clickable script link (CVE-2026-15920). - CVE-2026-15337 (Low): very long language codes as cache keys can consume memory, through the
set_language()view, which is not enabled by default.
How to check if you're exposed
python -c "import django; print(django.get_version())"
grep -rn "django.contrib.gis" */settings*.py
grep -rnE "GeometryField|PointField|PolygonField|__contains|__intersects|__within|dwithin" --include=*.py .
grep -rn "set_language" --include=*.py .
No django.contrib.gis in INSTALLED_APPS means the two GeoDjango CVEs are out of reach. The URLField XSS applies to any project that shows URLField values in the admin.
What to do now
- Upgrade to 6.0.8 or 5.2.17.
- After upgrading, test spatial lookups that pass strings or dicts. They may now raise, and the fix is to pass
GEOSGeometryobjects. - Review which staff accounts have view permission on models with spatial fields, since that was the route to the file write.
- Scan stored
URLFieldvalues for non http(s) schemes.
How this could have been avoided
- Limit who gets admin access. The file write needed a staff user with view permission on a spatial model. Fewer staff accounts, and view permission only where needed, shrinks the set.
- Run Django as a user that cannot write outside its data directory. A file write by the Django process user is only as dangerous as that user's rights, and read only app directories limit it.
- Block outbound network from the app tier except to known hosts. The request forgery half of CVE-2026-15307 needs a route out.
- Validate stored URLs on write, not only on display. A scheme check at save time removes the XSS source for
URLField.
Why it matters
A High rating on a framework does not mean every Django app is at risk. This release is a good example. The reachable set is staff users of GeoDjango projects. The exposure may be small, but the impact if you are in it is a write primitive on your server, which is worth acting on quickly.
Reachability analysis, checking whether your code calls the affected function or module, is what separates those two readings.
Quick check
How do you know whether CVE-2026-15307 is reachable in a Django project?
Check whether django.contrib.gis is installed and whether spatial lookups on models with spatial fields are exposed, for example through the admin changelist filter for staff users.
