Loading vulnerability…
Django contains an SQL injection vulnerability in QuerySet.annotate(), QuerySet.aggregate(), and QuerySet.extra() when column aliases are supplied through crafted dictionary expansion as keyword arguments. A malicious alias can be incorporated into generated SQL rather than being safely handled as an identifier. Affected versions are Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
3 valid exploits after Mallory filtered fakes, detection scripts, and README-only repos.
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 is a proof-of-concept (POC) exploit for CVE-2022-28346, a SQL injection vulnerability in Django's QuerySet.annotate(), aggregate(), and extra() methods. The repository contains a minimal Django project with a single 'User' model and two main endpoints: '/load_example_data' to populate the database and '/users/' which is intentionally vulnerable. The vulnerability is exposed via the 'order_by' and 'field' GET parameters in the '/users/' endpoint, which are used directly in Django ORM queries without proper sanitization, allowing for SQL injection. The repository includes Docker and docker-compose files for easy setup, and a setup script to initialize the environment. The exploit demonstrates the vulnerability but does not include a weaponized or automated attack payload; instead, it provides a vulnerable environment for testing and research. The main attack vector is network-based, targeting the web application via HTTP requests to the '/users/' endpoint.
This repository is a proof-of-concept (POC) exploit for CVE-2022-28346, a SQL injection vulnerability in Django's QuerySet.annotate(), aggregate(), and extra() methods. The codebase is a minimal Django project with a 'demo' app containing a vulnerable view at /demo. The vulnerability is demonstrated by passing a crafted 'field' parameter to the /demo endpoint, which is directly used in the annotate() method, leading to SQL injection. The README provides clear instructions for setup and exploitation, including a sample payload that extracts the SQLite version. The repository includes standard Django project files, a simple User model, and migration scripts. The main exploit capability is remote SQL injection via HTTP GET requests to the /demo endpoint. No detection scripts or fake code are present; this is a functional POC for the specified CVE.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
1 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.