SQL injection in Django FilteredRelation column aliases

This repository is not a standalone exploit against a remote third-party target; it is an intentionally vulnerable Django/PostgreSQL lab application designed to demonstrate and exercise a family of Django ORM SQL injection and query-manipulation issues. The core logic is in app/vulnapp/views.py, where multiple HTTP GET parameters are passed directly into ORM constructs that expect SQL identifiers or special keyword arguments rather than safely parameterized values. The app exposes separate routes for each candidate sink, including order_by(), annotate alias expansion, Trunc/Extract kind selection, values()/values_list() field selection, JSONField key transforms, explain() option names, FilteredRelation aliasing, dates()/datetimes() kind, distinct(*fields), in_bulk(field_name=), and unsafe filter(**request.GET.dict()) handling. Repository structure is compact: Dockerfile and docker-compose.yml build a reproducible environment with Django 3.2.4 and PostgreSQL; entrypoint.sh performs migrations, seeds the database, and launches the server; app/vulnapp/models.py defines Category and Person models; app/vulnapp/management/commands/seed.py populates sample records and creates a default admin user; app/vulnproj/urls.py maps the vulnerable routes; and app/vulnproj/settings.py configures PostgreSQL connectivity and permissive ALLOWED_HOSTS. The seeded data and JSON responses are intentionally designed to provide row content and differential behavior useful for testing boolean/error-based or data-extraction-oriented SQLi techniques. Main exploit capabilities provided by the application include: exposing multiple web-reachable SQLi-like primitives in Django ORM identifier contexts; enabling response-based calibration through returned rows and counts; demonstrating access-control impact via the /scoped/ endpoint where attacker-controlled _connector can weaken a pinned filter; and supporting extraction experiments via /list/ where a plain listing avoids count()-related column-count constraints. Because the repository is a vulnerable target/lab rather than a packaged offensive exploit script, there is no embedded shell payload or callback infrastructure, but it is clearly exploit-oriented and operational as a testbed for HTTP-based exploitation of the listed CVEs and related patterns.

This repository contains a Django web application (cve_2025_57833) and a corresponding exploit script (exploit.py) targeting a SQL injection vulnerability in the /api/search/ endpoint. The Django app is structured with standard project and app directories, including models for 'Author' and 'Book', migrations, views, and templates. The main vulnerability lies in the 'search' view, which allows user-controlled input to be used as a key in a dynamic annotation and filter, leading to a SQL injection vector when untrusted input is supplied in the 'search_field' parameter. The exploit.py script automates exploitation by sending a crafted payload to the /api/search/ endpoint. The payload abuses PostgreSQL's COPY TO PROGRAM feature to execute arbitrary shell commands on the server, specifically spawning a reverse shell back to the attacker's machine (localhost:8888 by default). The exploit demonstrates remote code execution via SQL injection, making it operational and dangerous if the target is misconfigured or exposed. Key endpoints include the vulnerable /api/search/ HTTP endpoint, the use of /tmp/f as a FIFO for the reverse shell, and the attacker's listener at localhost:8888. The repository is a functional proof-of-concept for CVE-2025-57833, demonstrating a real-world SQL injection to RCE chain in a Django/PostgreSQL environment.

This repository is a proof-of-concept (POC) for CVE-2025-57833, targeting Django 5.2. The project is a Django web application with a PostgreSQL backend, set up for easy deployment via Docker. The main vulnerability is demonstrated in the 'Books' view (vuln/views.py), where the POST /book/search endpoint accepts a user-controlled 'alias' field that is used directly in a FilteredRelation ORM annotation. This could allow an attacker to manipulate the ORM query, potentially leading to SQL injection or other attacks depending on the underlying ORM and database behavior. The repository includes all necessary Django project files, migration scripts, and Docker configuration for local testing and exploitation. The exploit is triggered by sending a crafted POST request to /book/search with a JSON body containing the 'alias' and optional 'author' fields. No external network endpoints are hardcoded; the attack is performed via HTTP requests to the local application.

This repository is a Django project demonstrating a proof-of-concept exploit for CVE-2025-57833, a SQL injection vulnerability in Django prior to version 4.2.23. The vulnerability arises when user-controlled data is used as dynamic aliases in annotate() or alias() calls, and is further exacerbated by the use of Python's eval() on user input. The main exploit is implemented in 'myapp/views.py' in the 'vulnerable_view' function, which accepts a JSON dictionary via the 'alias' GET parameter, evaluates its values, and uses them as dynamic annotations. This allows an attacker to inject arbitrary SQL or execute Python code. The vulnerable endpoint is exposed at '/vuln/' as defined in 'myproject/urls.py'. The repository includes standard Django project files, application code, and a virtual environment. The exploit is a POC and not weaponized, but demonstrates the risk of unfiltered user input in ORM annotations. The README provides detailed context, exploitation steps, and mitigation advice.

This repository is a comprehensive, intentionally vulnerable testbed for CVE-2025-57833, a critical SQL injection vulnerability in Django's ORM when using FilteredRelation with user-controlled field names. The structure includes a full Dockerized environment (Dockerfile, docker-compose), a Django web application (vuln_app), and multiple exploit and test scripts (local_attacks/exploit.py, exploit_test.py, test_sqli.py, run_test.py). The main exploit vector is the /api/vulnerable-search/ endpoint, which passes user input directly as a field name to FilteredRelation and select_related, allowing arbitrary SQL injection. The repository demonstrates both information disclosure and remote code execution (RCE) on PostgreSQL via COPY TO PROGRAM. It includes both vulnerable and safe code examples, automated exploit scripts, and extensive documentation for educational and research purposes. The exploit is operational, providing working payloads and automation for testing the vulnerability, and is not part of a larger exploit framework.