CVE-2026-1207

What it actually does

This is a SQL injection flaw in Django GeoDjango RasterField lookups when backed by PostGIS. A vulnerable Django application that accepts attacker-controllable raster lookup input can fail to safely constrain or parameterize the raster band index, allowing SQL fragments to be injected into generated PostgreSQL/PostGIS queries. Successful exploitation can let an attacker alter query logic, read limited data, or modify data accessible to the application database role. The CVSS vector indicates network exploitability, low attack complexity, no user interaction, and low-privileged access required. The issue affects Django 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28; unsupported series such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected. Exploit maturity is reported as weaponized, increasing practical risk even though it is not currently listed in CISA KEV.

Why it matters to the business

Applications using Django with PostGIS raster functionality may expose sensitive business data to unauthorized querying or allow unauthorized changes to database records if raster lookup parameters are reachable through user-facing features such as map, geospatial search, analytics, or imagery workflows. Because weaponized exploitation is reported and the vulnerability has been public for 187 days, internet-facing or partner-facing applications with affected Django versions should be treated as higher priority even without KEV listing. Operational consequences can include data leakage, data integrity issues, incident response costs, downtime for emergency patching, and regulatory notification obligations if protected data is exposed.

How an attack unfolds

An attacker first identifies a Django application that uses GeoDjango RasterField with a PostGIS database and exposes raster filtering, geospatial search, or map-related query parameters. The attacker authenticates if the feature requires an account, then submits crafted input where the raster band index is expected. In vulnerable versions, the band index is incorporated into generated SQL unsafely, so SQL syntax supplied by the attacker can alter the resulting PostGIS query. The attacker typically starts with syntax-breaking probes, then boolean or time-based payloads to confirm injection, and may progress to extracting database metadata or manipulating rows within the privileges of the Django database account. Because this is application-layer SQL injection, impact is bounded by reachable code paths, database permissions, query execution controls, and whether database error details are exposed.

How to fix it

Upgrade Django to a fixed supported release: 6.0.2 or later for the 6.0 series, 5.2.11 or later for the 5.2 series, or 4.2.28 or later for the 4.2 LTS series. If tracking Django directly from Git, include the upstream fix commit ba00558ddac694d92b05d12ecd2a5b7fcc1de025 or a later commit containing the fix. Unsupported Django branches such as 5.0.x, 4.1.x, and 3.2.x should be upgraded to a supported fixed release rather than patched ad hoc because they were not fully evaluated. As interim mitigation, restrict or disable application features that expose RasterField lookups with user-controllable band indexes, enforce strict server-side integer validation and allowlisting for band values, block obvious SQL metacharacters in raster-band parameters at the edge where feasible, and ensure the application database role has least-privilege permissions. Do not rely on WAF filtering as the primary fix.

How to confirm the fix worked

Confirm the running Django version is 6.0.2 or later, 5.2.11 or later, 4.2.28 or later, or a Git build containing commit ba00558ddac694d92b05d12ecd2a5b7fcc1de025. Review dependency lockfiles, container images, virtual environments, and deployed artifacts to ensure the patched package is actually in use. Verify whether the application uses django.contrib.gis, RasterField, and a PostGIS backend; systems that do not use RasterField/PostGIS are not expected to be exposed to this specific code path. Exercise raster lookup functionality with valid band indexes after patching to confirm no regression. In a controlled test environment only, submit non-integer or SQL-like band index input and confirm it is rejected by validation or safely handled without SQL syntax errors, time delays, or changed query results. Enable PostgreSQL statement/error logging temporarily if needed to verify that band indexes are no longer rendered as executable SQL fragments.

Typical attack path

1. Find a Django application with geospatial or raster-backed functionality using PostGIS.
2. Identify parameters or API fields that influence RasterField lookups, especially raster band selection.
3. Authenticate with a low-privileged account if the vulnerable feature is not public.
4. Send malformed band index values containing SQL metacharacters to trigger database errors or behavioral differences.
5. Confirm injection with boolean, union-style, or time-delay probes against PostgreSQL/PostGIS.
6. Enumerate accessible database metadata or application data using the Django database role privileges.
7. Optionally modify records or application state if the database role permits writes.
8. Cover tracks by reducing noisy probes after confirming exploitable syntax.

How to detect it

To determine whether exploitation already occurred, correlate web access logs, API gateway logs, WAF events, Django application logs, and PostgreSQL/PostGIS logs around endpoints that perform map, geospatial, imagery, raster, or search functions. Look for requests where parameters related to raster band selection contain quotes, comments, parentheses, semicolons, boolean operators, UNION queries, PostgreSQL functions, time-delay functions, or references to system catalogs. In PostgreSQL logs, look for syntax errors, invalid integer conversion errors, or unusual PostGIS queries involving raster functions near the same source IP, account, session, or request ID. Pay particular attention to authenticated low-privilege users repeatedly submitting malformed band values, requests that produce HTTP 500 responses, and sequences that progress from error probes to time-based or metadata-enumeration payloads. If database statement logging is available, examine generated SQL containing PostGIS raster functions and verify whether attacker-supplied text appears where a numeric band index should be. Also review database audit logs for unexpected SELECTs against sensitive tables, access to information_schema or pg_catalog, and unauthorized UPDATE/DELETE activity by the application database role.

• django.contrib.gis.db.models.fields.RasterField
• RasterField
• ST_Band(
• ST_Value(
• ST_Intersects(
• ST_Contains(
• ST_Union(
• band_index=
• band=
• pg_sleep(
• UNION SELECT
• information_schema
• pg_catalog
• OR 1=1
• ' OR '1'='1
• --
• /*
• */
• ;SELECT
• syntax error at or near
• unterminated quoted string
• invalid input syntax for type integer
• current_database()
• current_user
• version()

What your security team should do

• Inventory Django applications that use GeoDjango, PostGIS, or raster/geospatial features and prioritize internet-facing and partner-facing systems.
• Upgrade affected Django deployments to 6.0.2, 5.2.11, or 4.2.28 or later; move unsupported branches to a supported fixed series.
• Treat reachable vulnerable raster lookup endpoints as urgent because weaponized exploitation has been reported and public exposure has existed for months.
• Review application code for RasterField lookups where band index values are derived from HTTP parameters, API request bodies, form fields, or stored user input.
• Add explicit server-side validation requiring raster band indexes to be integers within expected ranges.
• Review PostgreSQL permissions for Django application users and remove unnecessary write, schema modification, superuser, file, extension, and cross-database privileges.
• Search historical web, application, WAF, and PostgreSQL logs for SQL injection probes against geospatial/raster endpoints.
• If suspicious activity is found, preserve logs, rotate potentially exposed credentials, review database access, and assess whether sensitive records were read or changed.