<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T10:05:15.061346+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bit-django-2026-15307</id>
    <title>BIT-django-2026-15307 — Server-side file-write and request forgery via spatial lookups</title>
    <updated>2026-10-02T10:05:15.372821+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Bitnami: django</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bit-django-2026-15307"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-344316</id>
    <title>EUVD-2026-344316</title>
    <updated>2026-10-02T10:05:15.372910+00:00</updated>
    <content>EUVD-2026-344316</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-344316"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-15307</id>
    <title>fkie_cve-2026-15307</title>
    <updated>2026-10-02T10:05:15.372927+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-15307"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-wvqv-fj8w-qmhm</id>
    <title>GHSA-wvqv-fj8w-qmhm — Django GeoDjango spatial lookups allow file writes and outbound requests through GDAL raster parsing</title>
    <updated>2026-10-02T10:05:15.372959+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: Django</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-wvqv-fj8w-qmhm"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2026-3496</id>
    <title>OESA-2026-3496 — python-django security update</title>
    <updated>2026-10-02T10:05:15.372991+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:22.03-LTS-SP4: python-django</p>
<p>A high-level Python Web framework that encourages rapid development and clean, pragmatic design.

Security Fix(es):</p>
<p>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&amp;apos;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.(CVE-2026-15307)</p>
<p>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 rou…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2026-3496"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11464-1</id>
    <title>openSUSE-SU-2026:11464-1 — python313-Django-6.0.8-1.1 on GA media</title>
    <updated>2026-10-02T10:05:15.373032+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>python313-Django-6.0.8-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:11464-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/pysec-2026-4035</id>
    <title>PYSEC-2026-4035 — Django GeoDjango spatial lookups allow file writes and outbound requests through GDAL raster parsing</title>
    <updated>2026-10-02T10:05:15.373052+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: django</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/pysec-2026-4035"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/rhsa-2026:59135</id>
    <title>RHSA-2026:59135 — Red Hat Security Advisory: Red Hat Ansible Automation Platform 2.5 Product Security and Bug Fix Update</title>
    <updated>2026-10-02T10:05:15.373079+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>django: Django: Remote code execution via GeoDjango spatial lookups aiohttp: AIOHTTP: Arbitrary code execution via untrusted input to CookieJar.load() JWCrypto: python-cryptography: python: JWCrypto: Memory exhaustion via crafted compressed JWE tokens tmp: path Traversal via unsanitized prefix/postfix enables directory escape awxkit: path traversal via YAML !include directive pyasn1: pyasn1: Denial of Service via crafted ASN.1 REAL values gitpython: GitPython: Environment variable exfiltration via attacker-controlled clone URL gitpython: GitPython: Arbitrary code execution via command injection due to unguarded Git options gitpython: GitPython: Arbitrary Code Execution via Joined Short Options Bypass gitpython: GitPython: Command Injection via Git option prefix abbreviation aiohttp: AIOHTTP: HTTP Request Smuggling via WebSocket Upgrade aiohttp: AIOHTTP: Denial of Service via malformed HTTP responses awx: project archive extraction allows path traversal file writes awx: webhook status callback SSRF leaks the Git PAT awx: notification backends allow SSRF and credential leakage gitpython: GitPython: Arbitrary file overwrite and read via unsafe git option forwarding GitPython: GitPython: Arbitrary file read via TagReference.create()</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/rhsa-2026:59135"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:3503-1</id>
    <title>SUSE-SU-2026:3503-1 — Security update for python-Django</title>
    <updated>2026-10-02T10:05:15.373127+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for python-Django</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2026:3503-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-15307</id>
    <title>UBUNTU-CVE-2026-15307</title>
    <updated>2026-10-02T10:05:15.373144+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:18.04:LTS: python-django, Ubuntu:Pro:20.04:LTS: python-django, Ubuntu:22.04:LTS: python-django, Ubuntu:24.04:LTS: python-django, Ubuntu:26.04:LTS: python-django</p>
<p>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.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-15307"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2649</id>
    <title>WID-SEC-W-2026-2649 — Django: Mehrere Schwachstellen</title>
    <updated>2026-10-02T10:05:15.373176+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen in Django ausnutzen, um beliebigen Programmcode auszuführen, Daten zu manipulieren, Cross-Site-Scripting-Angriffe durchzuführen oder einen Denial-of-Service-Zustand auszulösen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2649"/>
  </entry>
</feed>
