Django SQL Injection via _connector in QuerySet and Q Objects

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.

Repository contains a single Python exploit script, rtb_connector_sqli.py, plus README, license, and requirements. The script is a standalone Python requests-based exploit for CVE-2025-64459, a Django ORM SQL injection involving unsafe handling of the special Q()/_connector keyword when user input is passed directly into queryset filters. It is not tied to a framework. Primary capability is automated exploitation of vulnerable Django HTTP endpoints. The tool supports endpoint discovery, vulnerability confirmation, schema enumeration, and UNION-based data extraction. Based on the README and visible code, it uses Django debug error pages to extract FieldError details and parse SQL statements from traceback output, allowing it to automatically determine valid model fields, the base table name, and the number of selected columns. It then identifies a reflected column using marker delimiters and uses that position for extraction. The exploit exposes multiple operator modes through argparse subcommands: check, tables, columns <table>, dump <table>, users, query, shell, and auto. The users shortcut specifically targets the Django auth_user table and attempts to dump username, password, is_superuser, is_staff, and email fields. The query mode evaluates arbitrary SQL expressions, while shell provides an interactive enumeration/dumping workflow. Network behavior is straightforward: it creates a requests.Session, disables TLS verification warnings, optionally routes traffic through a user-supplied HTTP/HTTPS proxy, and sends GET requests to url + path with crafted query parameters. The default target path is /list, but the script includes a large built-in route wordlist for automatic discovery, including generic listing/search endpoints, PT-BR variants, Django ListView-style names, and API-style paths. It also references robots.txt and sitemap.xml in the README as discovery sources. The repository is a real exploit, not merely a detector. Its end goal is database read access through SQL injection, including credential dumping from Django’s auth tables. Because payloading is hardcoded around SQLi enumeration and extraction rather than customizable post-exploitation modules, maturity is best classified as OPERATIONAL.

Repository purpose: a minimal Django blog-style application intended to demonstrate CVE-2025-64459 (SQL injection in Django QuerySets/Q objects when a user-controlled dictionary is passed into Q(**kwargs)/queryset filtering). It is a PoC/demo app rather than a standalone exploit script. Key vulnerable logic: - posts/views.py::post_list builds query_params from request.GET and then constructs q_filter = Q(**query_params) and applies Post.objects.filter(q_filter). - Although it attempts to block filtering on 'status' (BLOCKED_FILTER_FIELDS = ['status']) and then forcibly sets query_params['status'] = 'published', the README states the vulnerability arises because an attacker can supply special keys like '_connector' and '_negated' in the query-parameter dictionary, causing Django to treat them as internal Q-object controls and enabling injection of arbitrary SQL fragments / query manipulation. Exploit capabilities (as implemented by the repo): - Remote, unauthenticated attack surface via HTTP GET parameters to the root path ('/'). - SQL injection / query manipulation leading to data exposure and bypass of intended constraints (e.g., viewing draft/archived posts despite enforced 'published' filter), and potentially broader SQL fragment execution depending on the exact affected Django versions and backend behavior. Repository structure: - django_project/: standard Django project scaffolding (settings, urls, wsgi/asgi). - posts/: single app containing Post model, admin registration, and the vulnerable views. - Dockerfile + entrypoint.sh: containerized deployment using gunicorn bound to :8000; entrypoint runs migrations and collectstatic. - pyproject.toml: pins dependencies, notably django==5.2.7. - staticfiles/: collected Django admin static assets (not exploit logic). Notable operational/security observations: - .env is included with a hardcoded Django SECRET_KEY and DEBUG=True (appropriate for a demo, but dangerous if reused in real deployments). - ALLOWED_HOSTS/CSRF_TRUSTED_ORIGINS include demo domains (django-cve.hyperf.app, cve.hyperf.app) and local dev origins.

This repository is a containerized CTF web challenge implementing a deliberately vulnerable Django application that demonstrates an ORM filter injection labeled as CVE-2025-64459. Core exploit capability: - The vulnerability is in src/shop/views.py where both product_list() and login_view() take all GET parameters (request.GET.dict()) and pass them directly into QuerySet.filter(**filters) without allowlisting or validation. - This enables attackers to inject special Django ORM filter control keys such as _connector=OR and _negated=True (as described in README.md) to alter query logic. Impact / what an attacker can achieve: - Auth bypass: /login/ uses User.objects.filter(**filters).first() and renders the dashboard if any user matches. By injecting conditions (e.g., username=admin with _connector=OR and is_superuser=True, or using _negated), an attacker can cause the query to return the admin user and view shop/templates/shop/dashboard.html, which displays user.secret_note (seeded with the flag). - Data exposure: The home page initially filters Product.objects.filter(is_public=True), but injected filters can negate or override this to reveal non-public products, including the seeded "Admin Access Token" product whose description contains the flag. Repository structure and purpose: - Infrastructure: Dockerfile builds a minimal Python 3.11 image; docker-compose.yml runs nginx (published on host port 6008) proxying to a gunicorn-served Django app (port 8000). nginx/nginx.conf sets basic headers and rate/connection limits. - Django project: src/core/* contains settings/urls/wsgi; a custom middleware (src/core/middleware.py) adds an X-Powered-By: Django/5.1.10 header. - App logic: src/shop/models.py defines Product and a custom User model (not Django auth). src/shop/views.py contains the intentionally vulnerable filtering logic. - Seeding: src/entrypoint.sh runs migrations and seeds SQLite (/tmp/db.sqlite3) with public products plus a non-public product containing the flag, and creates guest/admin users where admin.secret_note is the flag. Overall, this is not a standalone exploit tool but a vulnerable application plus README-provided curl examples demonstrating how to exploit the ORM injection via crafted HTTP GET parameters against / and /login/.

This repository is a Django-based helpdesk web application containing a critical access control vulnerability (CVE-2025-64459). The vulnerability is present in the 'search_conversations' view (helpdesk/views.py), where the presence of '_connector' or '_negated' GET parameters disables access control checks, allowing any authenticated user to enumerate and access all tickets, including those marked as confidential. Additionally, the 'conversation_detail' view lacks proper access checks, enabling any logged-in user to view the details (including sensitive personal and passport data) of any ticket by accessing /conversation/<id>/. The repository includes standard Django project structure with models for tickets, customers, and contact requests, as well as HTML templates for the user interface. The exploit does not require code execution on the target, only crafted HTTP requests as an authenticated user. No external network endpoints or IPs are hardcoded; all endpoints are local to the web application. The exploit is a proof-of-concept for a broken access control vulnerability, not a weaponized exploit.

This repository is a CTF challenge demonstrating a proof-of-concept exploit for CVE-2025-64459, a Django ORM filter injection vulnerability. The application is a simple merch shop built with Django 5.1.10, featuring endpoints for product listing and admin login. The vulnerable code is in 'src/shop/views.py', where user-supplied GET parameters are passed directly to Django ORM filter methods without sanitization. This allows attackers to inject special parameters (such as _connector=OR, _negated=True, or is_superuser=True) to bypass authentication or access hidden products. The README provides explicit exploit examples using crafted HTTP GET requests. The repository includes Docker and docker-compose files for deployment, and the database is seeded with a flag in the admin's secret note. The main attack vector is web-based, targeting the /login/ and / endpoints. No detection scripts or fake exploits are present; this is a functional POC exploit for the described vulnerability.

This repository is a Proof of Concept (PoC) for CVE-2025-64459, a critical SQL injection vulnerability in Django's ORM (Object Relational Mapper). The exploit demonstrates how an attacker can abuse the Q object constructor by injecting a malicious '_connector' key via dictionary unpacking, resulting in arbitrary SQL logic being inserted into the WHERE clause of a query. The repository is structured as a minimal Django project, with Docker and docker-compose files for easy setup. The main exploit logic resides in 'app/webapp/management/commands/poc.py', which creates sample users, simulates a malicious search payload, and prints the resulting SQL and query results. The PoC shows that an attacker can bypass authentication and enumerate admin users. The repository includes a README with detailed technical analysis, affected versions, reproduction steps, and remediation advice. No external network endpoints are used; the exploit is demonstrated locally within the Dockerized environment.