EUVD-2025-32691
GHSA-hpr9-3m2g-3j9p
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSubmit crafted dictionary keys via application input
-
DeliveryKeys expanded as **kwargs into annotate()/extra()
-
ExploitMalicious alias bypasses FORBIDDEN_ALIAS_PATTERN filter
-
ExecutionInjected SQL executes on MySQL/MariaDB
-
ImpactExfiltrate or tamper with database data
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Parameterized queries, prepared statements
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Persistence The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires an application to pass an attacker-controlled dictionary, via dictionary expansion (**kwargs), into QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), or QuerySet.extra(), such that untrusted input becomes a column alias; and the database backend must be MySQL or MariaDB (PostgreSQL, SQLite, and Oracle are not affected). The running Django version must be 4.2 <4.2.25, 5.1 <5.1.13, or 5.2 <5.2.7. Key limiting factors: in idiomatic Django code column aliases are hardcoded by developers rather than taken from user input, so the vulnerable pattern is uncommon; the backend restriction to MySQL/MariaDB further narrows exposure; no authentication or user interaction is required (PR:N/UI:N) once a vulnerable code path is reachable. |
| Impact | The input CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, base 9.8) rates this as critical network-exploitable, unauthenticated SQL injection with full confidentiality, integrity, and availability impact, and the PR:N metric confirms no authentication is required at the protocol level. However, these raw-severity signals conflict sharply with the real-world exploitation signals: EPSS is only 0.01% (2nd percentile), there is no CISA KEV listing (not actively exploited), and no public exploit code was identified in the provided data. The decisive nuance the CVSS score hides is the exploitation precondition - the flaw only triggers when an application passes an attacker-controlled dictionary via dictionary expansion as the **kwargs to QuerySet.annotate()/alias()/aggregate()/extra(), AND only on MySQL/MariaDB backends. In typical Django code, column aliases are developer-defined constants, not user input, so most deployments are not exploitable despite running an affected version. This is therefore a genuinely serious library defect that warrants prompt patching (it is a follow-up to CVE-2022-28346), but for the large majority of deployments it is a high-CVSS / low-realistic-risk issue rather than a mass-exploitation priority; the near-zero EPSS and absence of KEV/POC corroborate that assessment. |
| Exploit ScenarioDerived | A Django web application on a MySQL or MariaDB backend takes a user-supplied dictionary (e.g. derived from request parameters) and expands it as **kwargs into QuerySet.annotate() or .extra(), letting an attacker control the column alias string. The attacker crafts a key containing percent signs or hash characters (which the pre-patch FORBIDDEN_ALIAS_PATTERN failed to block) to break out of the alias context and inject SQL, reading or modifying database contents. No public exploit code was identified at time of analysis, and exploitation depends on this uncommon coding pattern rather than default behavior. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Oct 12, 2026
SQL injection in the Django ORM column-alias handling used by QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() affects Django 4.2 before 4.2.25, 5.1 before 5.1.13, and 5.2 before 5.2.7, but only when the application is backed by MySQL or MariaDB; PostgreSQL, SQLite, and Oracle are not affected. An attacker can only reach the flaw if the application itself expands an attacker-controlled dictionary (**kwargs) into those methods so that untrusted input becomes a column alias - a pattern that is uncommon in idiomatic Django code, which is why the independent assessment raises attack complexity to AC:H even though the published vector is 9.8/AC:L. Per the CVSS vector (PR:N/UI:N) no authentication or user interaction is required once that vulnerable code path exists, and the outcome is full read/write access to query data via injected SQL; at the time of analysis no public exploit code was identified and EPSS is negligible (0.01%, 2nd percentile), with vendor patches available. This is a follow-up to CVE-2022-28346, indicating the earlier alias denylist was incomplete.
Earlier versions of this analysis (1)
RemediationAI
Vendor-released patch: upgrade to Django 4.2.25, 5.1.13, or 5.2.7 (or later in each branch) as documented in https://www.djangoproject.com/weblog/2025/oct/01/security-releases/ and https://docs.djangoproject.com/en/dev/releases/security/; packaged installations should instead take the distribution build - USN-7794-1 for Ubuntu, DLA-4324-1 / DSA-6117-1 / DSA-6136-1 for Debian, RHSA-2025:18984 for Red Hat - since distro backports may carry different version numbers than upstream. Where immediate patching is impossible, the effective compensating control is to change application code, not the network layer: never pass user-controlled keys through dictionary expansion into annotate(), alias(), aggregate(), or extra(); wrap such calls behind an allowlist of hardcoded alias names and reject or normalize any key containing '#', whitespace, quotes, semicolons, percent signs, or SQL comment sequences before it reaches the ORM. This is the same validation posture as the earlier CVE-2022-28346 guidance, and because it is code-level it has no runtime side effects, though it requires auditing every dynamic call site. Migrating the affected workload to PostgreSQL, SQLite, or Oracle also removes exposure to this specific flaw but is usually a much larger operational change and may alter query semantics elsewhere. Note one patch side effect: version 4.2.25/5.1.13/5.2.7 now raises a ValueError for column aliases containing '#', so any legitimate code or test suite that previously used such aliases will fail after upgrading and must be adjusted. There is no indication of in-the-wild exploitation, so prioritization can follow normal risk-based patching, with MySQL/MariaDB-backed Django services that accept dynamic alias input treated as the highest queue.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Root cause is CWE-89 (SQL injection) in Django's database-layer alias validation. Django builds column aliases for annotate()/alias()/aggregate()/extra() from keyword-argument names; when a caller uses dictionary expansion, the keys become alias strings that flow into generated SQL. Django maintained a denylist regex (ForbiddenAliasPattern) to prevent dangerous characters in aliases, but the MySQL/MariaDB backend quoting context made certain characters - specifically the hash sign '#' - able to terminate or comment out the surrounding alias, yielding injectable SQL. The upstream fix (commits 41b43c74bda19753c757036673ea9db74acf494a and 43d84aef04a9e71164c21a74885996981857e66e) extends the pattern to r"['`\"\]\[;\s]|#|--|/\*|\*/" and updates the error text to mention hashes, rejecting aliases such as "ali#as"; tests in tests/annotations/tests.py and tests/aggregation/tests.py were updated accordingly. The vulnerability is a follow-up to CVE-2022-28346, the same class of alias-based SQL injection that a previous denylist round failed to fully close. CPE data (cpe:2.3:a:djangoproject:django) confirms the Django project itself as the affected component rather than any third-party plugin, and the flaw is backend-specific: only MySQL and MariaDB interpret the offending character in a way that permits injection, so the exposure surface is jointly determined by Django version and database backend. The independent assessment rates this AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, lower-complexity than the published AC:L because exploitation hinges on an application-level coding pattern (attacker-controlled keys passed via **kwargs) rather than a directly reachable network endpoint.
Know when Django gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
Sources disagree (Medium–Critical)AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
SQL injection with full C/I/A impact and no auth (PR:N), but AC:H because it depends on the uncommon pattern of user-controlled aliases via **kwargs and a MySQL/MariaDB backend.
AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N
vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.
CVSS VectorNVD
Lifecycle Timeline
5DescriptionNVD
An issue was discovered in Django 4.2 before 4.2.25, 5.1 before 5.1.13, and 5.2 before 5.2.7. QuerySet.annotate(), QuerySet.alias(), QuerySet.aggregate(), and QuerySet.extra() are subject to SQL injection in column aliases, when using a suitably crafted dictionary, with dictionary expansion, as the **kwargs passed to these methods (on MySQL and MariaDB).
Executive ViewAI
Organizations using Django 4.2 face moderate risk from CVE-2025-59681, a SQL injection vulnerability rated CVSS 7.1. Successful exploitation could allow attackers to execute arbitrary code or commands on affected systems, potentially leading to full system compromise. Organizations should apply vendor updates when available and consider compensating controls in the interim.
Apply vendor patch. If immediate patching is not feasible: (1) Deploy WAF rules to block injection patterns; (2) Restrict network access to affected components; (3) Enable enhanced logging for suspicious activity.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
SQL injection exploits the way applications construct database queries by mixing user input directly into SQL statements.
The package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9
In Django 1.10.x before 1.10.8 and 1.11.x before 1.11.5, HTML autoescaping was disabled in a portion of the template for
An issue was discovered in Django 3.2 before 3.2.14 and 4.0 before 4.0.6. Rated critical severity (CVSS 9.8), this vulne
Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input
Django before 1.11.27, 2.x before 2.2.9, and 3.x before 3.0.1 allows account takeover. Rated critical severity (CVSS 9.8
An authentication/authorization bypass in the djust Python live-view framework (versions prior to 1.0.7) lets unauthenti
Unauthenticated arbitrary Python module import in djust before 1.0.7 lets any client that can reach the WebSocket or SSE
Django 1.11 before 1.11.29, 2.2 before 2.2.11, and 3.0 before 3.0.4 allows SQL Injection if untrusted data is used as a
Cross-site scripting (XSS) vulnerability in the dismissChangeRelatedObjectPopup function in contrib/admin/static/admin/j
Forged content modification in django-page-cms through 2.0.13 lets unauthenticated remote attackers exploit five CSRF-ex
Cross-site request forgery in djust's Server-Sent-Events transport affects all versions prior to 1.0.7 and allows a cros
Unauthenticated remote attackers can read live Django view and session state and invoke server-side handlers through dju
Same weakness CWE-89 – SQL Injection
View allVendor StatusVendor
Ubuntu
Priority: Medium| Release | Status | Version |
|---|---|---|
| upstream | released | 4.2.25,5.1.13,5.2.7 |
| bionic | released | 1:1.11.11-1ubuntu1.21+esm12 |
| focal | released | 2:2.2.12-1ubuntu0.29+esm4 |
| jammy | released | 2:3.2.12-2ubuntu1.22 |
| noble | released | 3:4.2.11-1ubuntu1.11 |
| plucky | released | 3:4.2.18-1ubuntu1.5 |
| trusty | released | 1.6.11-0ubuntu1.3+esm8 |
| xenial | released | 1.8.7-1ubuntu5.15+esm9 |
| questing | released | 3:5.2.4-1ubuntu2 |
Debian
Bug #1116979| Release | Status | Fixed Version | Urgency |
|---|---|---|---|
| bullseye | fixed | 2:2.2.28-1~deb11u9 | - |
| bullseye (security) | fixed | 2:2.2.28-1~deb11u12 | - |
| bookworm | fixed | 3:3.2.25-0+deb12u1 | - |
| bookworm (security) | fixed | 3:3.2.25-0+deb12u2 | - |
| trixie | fixed | 3:4.2.27-0+deb13u1 | - |
| trixie (security) | fixed | 3:4.2.28-0+deb13u1 | - |
| forky, sid | fixed | 3:4.2.29-1 | - |
| (unstable) | fixed | 3:4.2.25-1 | - |
SUSE
Severity: High| Product | Status |
|---|---|
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP7 | Fixed |
| SUSE Package Hub 15 SP6 | Fixed |
| openSUSE Leap 15.6 | Fixed |
| openSUSE Leap 16.0 | Fixed |
| openSUSE Tumbleweed | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP7 | Fixed |
| openSUSE Leap 15.6 | Fixed |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Fixed |
| SUSE Package Hub 15 SP6 | Fixed |
Exploit-DB