Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Not in CISA KEV

CVE-2026-15307 Django

Fix: django/django@115ffd0

CVE-2026-15307 is a CWE-73 vulnerability. A fix is available — see the affected versions and patch details below.

Server-side file-write and request forgery via spatial lookups

Also known asBIT-django-2026-15307
Published
Aug 4, 2026
Updated
Aug 20, 2026
Affected
25 versions
Patched
See advisory
Exploits
None indexed
Exploitation data as of Sep 19, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • A successful exploit gives an attacker total control of the affected component, not partial access.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-15307.

EPSS Exploitation Probability

via FIRST.org ↗
0.9%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs58th percentile — riskier than 58% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Description

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.

Detection & mitigation playbook

Vulnerability
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for the affected component, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    No patched version of the affected component has shipped for CVE-2026-15307 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-15307 can be triaged on real exposure rather than presence alone.

Tailored to CVE-2026-15307. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

Red Hat products that are built with Django framework do not implement GeoDjango or GIS capabilities.

ProductFixed inAdvisory
Red Hat Ansible Automation Platform 2.5 for RHEL 8python3.12-django-0:5.2.17-1.el8apRHSA-2026:59135
Red Hat Ansible Automation Platform 2.6 for RHEL 10python-django-0:5.2.17-1.el10apRHSA-2026:59136
Red Hat Ansible Automation Platform 2.7 for RHEL 10python-django-0:5.2.17-1.el10apRHSA-2026:59137
Red Hat Ansible Automation Platform 2.2ansible-automation-platform/bootc-automation-portal-rhel9:1788943531RHSA-2026:66003
Red Hat Ansible Automation Platform 2.5ansible-automation-platform-25/hub-rhel8:1787101922RHSA-2026:59159
Red Hat Ansible Automation Platform 2.6ansible-automation-platform-26/hub-rhel9:1787220598RHSA-2026:59155
Red Hat Ansible Automation Platform 2.7ansible-automation-platform-27/lightspeed-rhel9:1787217531RHSA-2026:59153

Frequently Asked Questions

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
O3 Security · Impact-Aware SCA

Is CVE-2026-15307 in your dependencies?

O3 Security finds CVE-2026-15307 across dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

CVE-2026-15307: Django RCE | O3 Security