EUVD-2026-52747
GHSA-wvqv-fj8w-qmhm
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
ReconObtain staff credentials via phishing or credential stuffing
-
DeliveryAuthenticate to Django admin interface
-
ExploitNavigate to changelist for any spatial-field model
-
InstallInject malicious str or dict as spatial lookup filter parameter
-
C2Django ORM passes value unvalidated to GDALRaster constructor
-
ExecuteGDAL driver writes file to disk or issues outbound SSRF request
-
ImpactEscalate file write to RCE or harvest internal metadata
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V5 - File Handling File name/path control
|
| Exploitation Conditions | Exploitation requires the attacker to be authenticated as a Django staff user (is_staff=True) with at least view-level Django permissions on any model containing a GeoDjango spatial field (PointField, PolygonField, RasterField, or any other django.contrib.gis field type). That model must be registered with the Django admin site, which is the standard deployment pattern for GeoDjango applications that expose spatial data in the admin. The attack surface is the admin changelist filtering mechanism via ModelAdmin.lookup_allowed(), which allows staff users with view permissions to apply ORM lookups - this is a default Django admin behavior, not a misconfiguration. The specific impact depends on which GDAL raster drivers are compiled into the server's GDAL installation: file-write impact requires a driver supporting write mode (common in most GDAL builds), while SSRF requires a driver supporting network/virtual filesystem paths (also common). Deployments that do not use django.contrib.gis at all are entirely unaffected. The attack cannot be performed by unauthenticated users or by authenticated non-staff users. |
| Impact | The Django security team rates CVE-2026-15307 as 'high' severity under their internal policy. No formal CVSS score or EPSS probability was published with this advisory, so all risk signals must be inferred from the description and commit diff. The attack vector is network-accessible via the Django admin web interface, requiring staff-level authentication at low privilege (is_staff=True with view permissions), with low attack complexity once credentials are obtained. The impact combination is serious: SSRF can expose internal services, cloud metadata endpoints (e.g., 169.254.169.254), and authenticated internal APIs; file writes - depending on writable directories and GDAL driver availability - can overwrite Python modules, startup scripts, or other artifacts enabling remote code execution. The absence of a CVSS vector, KEV listing, and any reported exploitation in the wild tempers urgency somewhat. However, the Django admin is a well-known, frequently targeted attack surface, and staff credentials are routinely targeted in phishing and credential stuffing campaigns. The effective attack surface is narrowed to deployments that have the django.contrib.gis module active with spatial model fields registered in the admin - a meaningful but not negligible subset of the broader Django ecosystem. The SSRF vector is relatively high-impact in cloud environments where metadata services are accessible from the application process. |
| Exploit ScenarioDerived | An attacker who has obtained Django staff credentials via phishing or credential stuffing logs into the Django admin and navigates to the changelist view of any model that contains a GeoDjango spatial field. The attacker crafts a filter query parameter containing either a serialized GDAL raster dict (causing GDAL to create a new file on the server's filesystem in a writable directory) or a VSI network path string such as /vsicurl/http://169.254.169.254/latest/meta-data/ (causing the Django process to issue an outbound HTTP request to the cloud metadata service). No public exploit code is identified at time of analysis, but the attack path is straightforward for anyone familiar with GDAL's virtual filesystem interface, as the relevant GDAL driver names and VSI path schemes are publicly documented. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 04, 2026
Server-side file-write and server-side request forgery (SSRF) in Django's GeoDjango spatial lookups expose authenticated staff users as an attack surface capable of writing arbitrary files to disk or issuing outbound network requests as the Django process user. Affected are Django 5.2 (before 5.2.17) and 6.0 (before 6.0.8), where the Django admin changelist's standard filter mechanism made the flaw reachable by any staff account holding view permissions on a model with a spatial field. Depending on the GDAL raster driver available on the server, file writes can escalate to remote code execution. No public exploit is identified at time of analysis; patched releases Django 5.2.17 and 6.0.8 were issued August 4, 2026.
RemediationAI
Upgrade to Django 5.2.17 or Django 6.0.8, both released August 4, 2026, which are the vendor-confirmed patched versions. Signed release packages are available at https://www.djangoproject.com/download/5.2.17/tarball/ and corresponding wheel files at https://www.djangoproject.com/download/5.2.17/wheel/; checksums are published at https://www.djangoproject.com/download/5.2.17/checksum/. If immediate upgrade is not possible, the most targeted compensating control is to remove staff users' view permissions on any admin-registered model containing a spatial field, which closes the lookup_allowed() attack path but prevents those users from accessing those model views in the admin. Alternatively, un-register spatial models from the Django admin entirely until patching is complete, at the cost of losing admin visibility into those models. A network-level compensating control - adding strict egress filtering at the firewall to block unexpected outbound connections from the Django application server process - mitigates the SSRF vector but leaves the file-write vector unaddressed. The raster security considerations documentation at https://docs.djangoproject.com/en/dev/ref/contrib/gis/gdal/#raster-security provides guidance on how to continue using str and dict types in spatial lookups after upgrading by wrapping them explicitly in GDALRaster().
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The vulnerability resides in Django's contrib.gis (GeoDjango) module, specifically in how spatial lookup values are processed by the GDALRaster constructor within the ORM's get_db_prep_value method. GDAL (Geospatial Data Abstraction Library) supports a virtual filesystem (VSI) layer that allows drivers to open paths using network protocols (e.g., /vsicurl/ for HTTP, /vsis3/ for S3) or to create new raster files on disk when passed a dict definition. Prior to the fix, the ORM forwarded raw str and dict types - which are valid for model field assignment - directly into spatial lookups without distinguishing that lookup contexts carry different trust semantics. A serialized dict representing a raster definition would cause GDAL to create a new file, while a crafted str containing a VSI path would trigger an outbound network request. The fix introduces a DisallowedRasterLookup exception (subclass of SuspiciousOperation) and a new check_raster_lookup_value() classmethod on GDALRaster that blocks dict and str types in lookup contexts unless the caller explicitly wraps them in GDALRaster(), making the intent to write or fetch explicit. No CWE identifier was provided in the source data; the root cause class is improper input validation - specifically, conflating the semantics of field assignment with ORM lookup evaluation.
Know when Django gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Staff authentication required (PR:L); SSRF and file-write can affect resources beyond the Django process boundary (S:C); exploitable over the network via the admin interface (AV:N).
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Primary rating from Vendor (CNA).
CVSS VectorVendor
Lifecycle Timeline
2Description PRE-NVD
Blast Radius
ecosystem impact- 1 pypi packages depend on django (1 direct, 0 indirect)
Ecosystem-wide dependent count for version 6.0a1.
Articles & Coverage 1
Executive ViewAI
Django versions 5.2 (before 5.2.17) and 6.0 (before 6.0.8) contain a critical flaw in GeoDjango spatial lookups that allows authenticated staff users to write arbitrary files or issue network requests as the Django process, with potential escalation to remote code execution via GDAL drivers. Any organization running these versions exposes internal users as a direct RCE vector.
Vendor-released patch: Django 5.2.17 and 6.0.8. Interim: restrict staff admin console access to high-trust users only; disable unnecessary GDAL raster drivers; monitor application logs for anomalous file-write or outbound requests from Django processes.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
The package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9
In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for
An issue was discovered in Django 3.2 before 3.2.14 and 4.0 before 4.0.6. Rated critical severity (CVSS 9.8), this vulne
Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input
Django before 1.11.27, 2.x before 2.2.9, and 3.x before 3.0.1 allows account takeover. Rated critical severity (CVSS 9.8
An authentication/authorization bypass in the djust Python live-view framework (versions prior to 1.0.7) lets unauthenti
Unauthenticated arbitrary Python module import in djust before 1.0.7 lets any client that can reach the WebSocket or SSE
Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a
Cross-site scripting (XSS) vulnerability in the dismissChangeRelatedObjectPopup function in contrib/admin/static/admin/j
Forged content modification in django-page-cms through 2.0.13 lets unauthenticated remote attackers exploit five CSRF-ex
Cross-site request forgery in djust's Server-Sent-Events transport affects all versions prior to 1.0.7 and allows a cros
Unauthenticated remote attackers can read live Django view and session state and invoke server-side handlers through dju
Same weakness CWE-73 – External Control of File Name or Path
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Linux Enterprise Module for Package Hub 15 SP7 | Fixed |
| openSUSE Leap 16.0 | Fixed |
| openSUSE Tumbleweed | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP7 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.6 | Affected |
Exploit-DB