<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 14:11:11 +0000</lastBuildDate>
    <item>
      <title>BIT-django-2026-15920 — Potential cross-site scripting via URLField values in the admin</title>
      <link>https://cve.radiocsirt.org/vuln/bit-django-2026-15920</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: django&lt;/p&gt;
&lt;p&gt;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.&#13;
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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Bitnami: django&lt;/p&gt;
&lt;p&gt;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.&#13;
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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bit-django-2026-15920</guid>
    </item>
    <item>
      <title>EUVD-2026-344161</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-344161</link>
      <description>EUVD-2026-344161</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-344161</guid>
    </item>
    <item>
      <title>fkie_cve-2026-15920</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-15920</link>
      <description>&lt;p&gt;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.&#13;
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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&#13;
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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-15920</guid>
    </item>
    <item>
      <title>GHSA-8rmj-xgq5-w9qm</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8rmj-xgq5-w9qm</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8rmj-xgq5-w9qm</guid>
    </item>
    <item>
      <title>OESA-2026-3496 — python-django security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-3496</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: python-django&lt;/p&gt;
&lt;p&gt;A high-level Python Web framework that encourages rapid development and clean, pragmatic design.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;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;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)&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: python-django&lt;/p&gt;
&lt;p&gt;A high-level Python Web framework that encourages rapid development and clean, pragmatic design.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;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;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)&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-3496</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11464-1 — python313-Django-6.0.8-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11464-1</link>
      <description>&lt;p&gt;python313-Django-6.0.8-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;python313-Django-6.0.8-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11464-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:3503-1 — Security update for python-Django</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:3503-1</link>
      <description>&lt;p&gt;Security update for python-Django&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for python-Django&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:3503-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-15920</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-15920</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: python-django, Ubuntu:Pro:16.04:LTS: python-django, 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&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: python-django, Ubuntu:Pro:16.04:LTS: python-django, 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&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-15920</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2649 — Django: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2649</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2649</guid>
    </item>
  </channel>
</rss>
