SQL Injection in Django RasterField band index parameter

This repository is a runnable proof-of-concept environment for CVE-2026-1207, demonstrating a SQL injection flaw in Django GIS RasterField query handling. It is not an exploit framework module; it is a standalone Django project built to reproduce the issue locally. Repository structure: the root contains a standard Django project with manage.py, a project package web/, and a vulnerable app vuln/. The vuln app defines RasterModel and RasterRelatedModel in vuln/models.py using django.contrib.gis.db.models.RasterField and PointField. The vulnerable HTTP route is exposed through web/urls.py -> vuln/urls.py as /book/search. The core vulnerable logic is in vuln/views.py, where Books.get() reads the attacker-controlled GET parameter band and passes it directly into RasterModel.objects.filter(rast__contains=(rast, band)). A GDALRaster object is constructed inline to satisfy the lookup. The query is printed and executed with qs.count(), making the injection observable. Exploit capability: the code enables web-based SQL injection against the backend PostgreSQL/PostGIS database through the band parameter. The README and inline comment provide a time-based blind payload using pg_sleep(3): 1);select '1'||pg_sleep(3) --. This confirms that arbitrary SQL fragments can be injected into the generated GIS SQL. The exploit does not include post-exploitation automation, credential dumping, or shell payloads; it is focused on proving injection. Environment and targeting: the devcontainer setup provisions Python 3.11, Django 5.2.9, psycopg2-binary, GDAL/GEOS/PROJ libraries, and a PostGIS container with postgis and postgis_raster extensions enabled. The web service is exposed on port 8087 and the database service is reachable as db:5432. The README explicitly states the issue affects django.contrib.gis RasterField and demonstrates exploitation via http://localhost:8087/book/search. Assessment: this is a real exploit POC rather than a scanner or detection-only script. Its maturity is POC because it demonstrates exploitation with a hardcoded payload example but does not provide a generalized exploitation toolkit or customizable weaponized payload handling.