REDHAT-BUG-2511095: High severity Django Django vulnerability
An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before 6.0.8. GeoDjango spatial lookups optimistically parse the right-hand-side value as a raster by passing it to the django.contrib.gis.gdal.GDALRaster constructor. Any value used in a spatial lookup against a GeometryField or RasterField reaches this constructor, including untrusted input, for example a spatial-field filter submitted through the Django admin changelist query string by a staff user with view permission. A dict, or a str holding its JSON representation, is opened in write mode regardless of the constructor's write=False default, allowing a file with an attacker-chosen name and contents to be written through a file-backed GDAL driver. Any other str is treated as a datasource, allowing an outbound network request through a GDAL virtual filesystem handler. Writing a file to a location later imported by the application can result in remote code execution. Earlier, unsupported Django series (such as 5.1.x, 5.0.x, and 4.2.x) were not evaluated and may also be affected. Django would like to thank Bence Nagy, localhost-detect, and kimchunbok for reporting this issue.
Affected Software
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using GeoDjango spatial lookups against GeometryField or RasterField are exposed when attacker-controlled values can reach those lookups. One documented path is a Django admin changelist query submitted by a staff user who has view permission.
What does an attacker need to exploit it?
The attacker needs to supply a value used as the right-hand side of a GeoDjango spatial lookup. A dict, or a string containing its JSON representation, can trigger file creation through a file-backed GDAL driver; other strings can cause outbound network requests through a GDAL virtual filesystem handler.
What is the practical impact of successful exploitation?
An attacker can write a file with an attacker-chosen name and contents. If that file is written to a location that the application later imports, the result can be remote code execution.
Which releases address the issue?
The issue affects Django 5.2 before 5.2.17 and Django 6.0 before 6.0.8. Earlier unsupported series, including 5.1.x, 5.0.x, and 4.2.x, were not evaluated and may also be affected.