Django GeoDjango CVE-2026-114582

Exploitation requires that the application pass attacker-influenced string input into django.contrib.gis.gdal.SpatialReference, GEOSGeometry.transform(), OGRGeometry.transform()/srs setter, GDALRaster.transform(), or the GDALRaster srs/srid setters - i.e. GeoDjango must be in use with a code path that forwards untrusted SRS strings to GDAL. Limiting factors: the vulnerable surface is confined to applications that expose these GIS APIs to external input (not a default Django site), so an app that never feeds user data to SpatialReference is unaffected. Even after patching, full file/network blocking is only enforced on GDAL 3.9 or higher; on older GDAL the fix blocks the 'dict:'/'esri::dict:' parser bypass but cannot otherwise restrict resolution, and Django only emits a system-check warning. Impact is read-oriented (SSRF to internal/attacker hosts and local file reads), with no integrity or availability effect.

This is a moderate, condition-dependent SSRF/local-file-read (CWE-918) in Django's GeoDjango stack, not a high-urgency mass-exploitation issue. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) with only low confidentiality impact (VC:L) and no integrity or availability impact yields 6.9 (Medium), and this matches the mechanism: attacker-supplied strings reach GDAL, which by default resolves URLs and reads files, so the payoff is SSRF and file-content disclosure rather than code execution. No EPSS score, KEV listing, or PoC/exploit reference was provided - the only references are the vendor advisory and four patch commits - so exploitation signals are absent, consistent with the vuln.today 'this_month' (not act_now/emergency) decision label. The network vector and PR:N would normally suggest easy remote reach, but real-world exploitability is gated by an application-design precondition absent from the raw vector: the app must actually pass untrusted input into SpatialReference/transform()/srs/srid. Treat this as a real but prioritizable patch item, not an emergency; EPSS and SSVC-automatable signals were not supplied and cannot be assessed.

A web application accepts a user-controlled coordinate-system identifier and passes it to django.contrib.gis.gdal.SpatialReference (or a transform()/srs/srid setter). An attacker submits a crafted spatial reference string containing a URL or local file path; GDAL (below 3.9, or before the Django fix) resolves it, causing the server to issue an outbound request to an attacker or internal host, or to read a local file. No public exploit code is identified at time of analysis.