Source: python-django Version: 3:5.2.16-1 Severity: important Tags: security upstream X-Debbugs-Cc: [email protected], Debian Security Team <[email protected]>
Hi, The following vulnerabilities were published for python-django. CVE-2026-15307[0]: | 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. CVE-2026-15337[1]: | An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before | 6.0.8. `django.utils.translation.check_for_language()` is subject to | a potential denial-of-service attack when given many distinct, very | long language codes, which are retained as keys in an in-memory | cache and consume process memory. Such codes reach the function | through the `django.views.i18n.set_language()` view, which is not | routed by default. The consumed memory is bounded, since request | data is limited by the `DATA_UPLOAD_MAX_MEMORY_SIZE` setting | (default 2.5 MB) and the cache holds a fixed maximum number of | entries. 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 Jaeyoung Jang for reporting this issue. CVE-2026-15830[2]: | An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before | 6.0.8. GeoDjango's `django.contrib.gis.geos.GEOSGeometry` is subject | to a potential denial-of-service when parsing deeply nested | `GEOMETRYCOLLECTION` objects supplied as well-known text (WKT), | well-known binary (WKB), or hex-encoded WKB, which triggers | unbounded recursion and a segmentation fault in the underlying GEOS | library. Spatial field lookups and the | `django.contrib.gis.forms.GeometryField` form field are also | affected. 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 Andrew MacPherson and kimchunbok_ for reporting this | issue. CVE-2026-15920[3]: | An issue was discovered in Django 5.2 before 5.2.17 and 6.0 before | 6.0.8. `django.contrib.admin.utils.display_for_field()` renders | `URLField` values as clickable links in the admin without validating | the URL. A value stored with an unsafe scheme is displayed as a link | on changelist and read-only admin pages, which allows cross-site | scripting against staff users who click the link. Exploitation | requires the unsafe value to already be stored in the database. | `URLField` validation through a `ModelForm` or the admin rejects | unsafe schemes, so this affects applications that persist `URLField` | data without running model validation, for example through direct | queryset writes, deserialization, or bulk import of untrusted input. | Django would like to thank Egor Saltykov for reporting this issue. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-15307 https://www.cve.org/CVERecord?id=CVE-2026-15307 [1] https://security-tracker.debian.org/tracker/CVE-2026-15337 https://www.cve.org/CVERecord?id=CVE-2026-15337 [2] https://security-tracker.debian.org/tracker/CVE-2026-15830 https://www.cve.org/CVERecord?id=CVE-2026-15830 [3] https://security-tracker.debian.org/tracker/CVE-2026-15920 https://www.cve.org/CVERecord?id=CVE-2026-15920 Please adjust the affected versions in the BTS as needed. Regards, Salvatore
