The vulnerability arises from GeoDjango’s spatial lookup mechanism that parses user‑supplied values using the GDALRaster constructor. Because this constructor is called with write mode enabled for dictionary inputs or stringified dictionaries, an attacker can create or overwrite files in locations determined by the attacker. For other string inputs, the constructor treats them as datasources, potentially triggering outbound network requests through the GDAL virtual filesystem. An attacker with a staff view permission can craft query strings targeting these lookups, leading to the creation of files that, if later imported by the application, can execute code on the server.

This flaw is present in all Django 5.2 releases prior to 5.2.17 and in Django 6.0 releases before 6.0.8. Earlier Django series such as 5.1.x, 5.0.x, and 4.2.x may also be affected because the code paths were not evaluated in those releases. Any deployment using GeoDjango’s spatial lookups—particularly in the admin changelist query strings accessed by staff users—needs assessment.

The CVSS score of 8.7 indicates a high severity, and although the EPSS score is currently unavailable, the lack of listing in the CISA KEV catalog suggests no publicly confirmed exploits yet. The vulnerability requires that an authenticated staff member craft a special request to the server, and successful exploitation would allow an attacker to write arbitrary files or make outbound requests via GDAL, providing a pathway to remote code execution. The attack vector is therefore a server‑side request forged through a legitimate view‑only account and is not trivial but under the control of a privileged user within the organization.