Loading vulnerability…
CVE-2022-34265 is an SQL injection vulnerability in Django database functions Trunc() and Extract(). Django versions 3.2 before 3.2.14 and 4.0 before 4.0.6 insufficiently validate the SQL-affecting kind and lookup_name arguments. If an application supplies attacker-controlled data to either argument, the value can alter the generated SQL statement. Applications that restrict these arguments to a known-safe allowlist are unaffected.
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.
2 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-34265, a SQL injection vulnerability in Django versions 3.2.x prior to 3.2.14 and 4.0.x prior to 4.0.6. The repository contains a minimal Django project and app ('vuln') with intentionally vulnerable views. The main exploit is demonstrated via two HTTP endpoints: '/extract/' and '/trunc/', which accept user-supplied GET parameters ('lookup_name' and 'kind', respectively) that are directly passed to Django's Extract and Trunc database functions. This allows an attacker to inject arbitrary SQL, as shown in the README with time-based injection using PG_SLEEP. The repository includes Docker and docker-compose files for easy setup, a PostgreSQL backend, and all necessary Django configuration. The exploit demonstrates the risk of arbitrary SQL execution, including the potential for data exfiltration or destructive actions such as DROP TABLE. The code is structured for demonstration and educational purposes, not for weaponization.
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.
2 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A Django SQL-injection vulnerability involving Trunc(kind) and Extract(lookup_name) arguments.
A SQL injection vulnerability in Django caused by improper validation of parameters to Trunc() and Extract(), enabling unexpected SQL execution.
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.