TL;DR: CVE-2025-64459 is a critical SQL injection flaw in Django ORM query construction that can let remote attackers alter database queries through crafted filter inputs, according to CYCOGNITO. The issue turns exposed search and API parameters into a direct data confidentiality and integrity risk, especially where legacy or internet-facing deployments still rely on dynamic query handling.
At a glance
What this is: CVE-2025-64459 is a critical Django ORM SQL injection flaw that lets crafted filter dictionaries reshape query logic and inject arbitrary SQL.
Why it matters: It matters because exposed Django apps often hide this risk behind search, filter, and API parameters, so patching and query-path review become urgent for application, data, and identity-adjacent teams.
By the numbers:
- CVE-2025-64459 affects Django 5.1 versions earlier than 5.1.14, Django 4.2 versions earlier than 4.2.26, and Django 5.2 versions earlier than 5.2.8.
Context
CVE-2025-64459 is a framework-level SQL injection issue, not a simple coding mistake in one application. The risk emerges when Django’s ORM turns flexible filter structures into database queries, because user-controlled input can influence how conditions are combined and executed.
That makes the issue relevant to application teams, platform owners, and security teams that rely on web applications to mediate database access. In identity-heavy portals, APIs, and admin tools, query construction defects can expose sensitive records even when authentication and access controls appear sound.
Key questions
Q: What fails when user input can shape ORM query structure in Django?
A: The trust boundary fails between the web layer and the database layer. Instead of passing harmless filter values, the application can pass attacker-influenced query structure into the ORM, which may generate unsafe SQL. The result is not just data leakage. It can also enable integrity loss if the service account has broader database permissions than it should.
Q: Why do exposed Django filter endpoints increase SQL injection risk?
A: They combine remote reach with predictable query handling. Search, reporting, and advanced filter features often accept nested parameters or JSON bodies that developers expand into ORM calls. If those inputs are not tightly constrained, an attacker can use them to alter query construction rather than merely change search values.
Q: What signs suggest a Django application may still be exposed?
A: Look for internet-facing assets on unsupported or unpatched Django branches, endpoints that accept rich filter structures, and services that expose search or reporting features through JSON or nested query parameters. Those patterns increase the likelihood that user input reaches ORM query assembly.
Q: Should teams prioritise patching over database hardening for this issue?
A: Patch first, because the flaw exists in query generation itself. But database hardening still matters because least-privilege accounts can limit what a successful injection can read or modify, reducing the blast radius if an exposed application is reached before remediation.
Technical breakdown
How Django ORM query construction becomes injectable
Django ORM usually protects developers from hand-built SQL by translating Python query objects into database statements. CVE-2025-64459 appears where QuerySet.filter(), QuerySet.exclude(), QuerySet.get(), and Q() accept a specially crafted dictionary expanded with ** as the _connector argument. That changes how conditions are combined in the query tree, which is the structural layer that determines SQL logic before the database ever sees the statement. Once an attacker influences that tree, the ORM can emit unsafe SQL even though the application never writes raw queries.
Practical implication: Validate any code path that passes user-controlled structures into ORM query composition, especially advanced filter builders.
Why flexible search endpoints raise the attack surface
The vulnerable pattern becomes more dangerous when applications expose rich filtering, nested query parameters, JSON bodies, or search builders to external users. Those features create a translation layer between untrusted input and database logic, and that translation layer is where injection risk appears. In practical terms, the more expressive the filter syntax, the harder it is to reason about whether the ORM receives only safe field names and values or attacker-shaped connector logic. The article also shows why legacy or internet-facing deployments magnify the problem: they increase both discoverability and reach.
Practical implication: Review externally reachable endpoints that turn request data into dynamic ORM expressions, not just raw SQL calls.
Why patched versions still require exposure review
The advisory gives fixed versions for supported branches, but it also notes that older unsupported branches may share the same vulnerable logic. That means patching is necessary but not sufficient when you have frozen services, inherited apps, or third-party deployments that are hard to inventory. The real architecture issue is not only version status. It is whether any service still lets external input flow into query assembly without strong constraints on connector semantics, field selection, and database privileges.
Practical implication: Inventory all Django deployments, confirm branch status, and treat unsupported versions as exposure candidates until proven otherwise.
Threat narrative
Attacker objective: The attacker aims to inject arbitrary SQL through Django query paths to extract or modify sensitive data in the backend database.
- Entry occurs when an attacker reaches an internet-facing Django application that accepts user-controlled filter parameters or search structures.
- Credential access is not required because the flaw lets the attacker manipulate ORM query composition directly through crafted dictionaries and connector handling.
- Escalation happens when the malformed query tree is converted into SQL that reads or alters data outside the application’s intended logic.
- Impact is confidentiality and integrity loss in the database layer, especially on portals and APIs that expose sensitive records.
Breaches seen in the wild
- JADEPUFFER agentic ransomware 2026: The first documented agentic ransomware used harvested keys, default MinIO credentials and a default Nacos signing key to wipe a database.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Query-tree injection is the core governance failure here: the dangerous boundary is not the database itself but the ORM layer that decides how untrusted filter structures become SQL. When that boundary accepts attacker-shaped connector logic, application security assumptions about safe abstraction collapse. Practitioners should treat ORM translation paths as security-sensitive code paths, not just developer convenience.
Internet-facing search and filter features create a hidden data-access problem: rich query syntax often looks like usability rather than exposure, but it becomes a direct path into the database when the framework accepts nested or dynamic filters. This is especially relevant where portals, APIs, and admin-style tools sit on public infrastructure. The practical conclusion is to govern query expressiveness as an attack surface, not a product feature.
Legacy Django branches are an exposure multiplier, not a versioning footnote: the article’s warning about unsupported series shows how often framework risk survives outside standard patch windows. That creates a governance gap between inventory, lifecycle management, and real attack surface. Teams need to assume that untracked Django instances, especially frozen services, may still carry the vulnerable logic until proven otherwise.
Least privilege at the database layer matters more when application logic is injectable: once query construction is compromised, the remaining containment boundary is the database account and its permissions. Overly broad accounts turn a framework flaw into full-table exposure or destructive writes. Security teams should treat privilege scope as the last meaningful limiter on SQL injection blast radius.
Django query safety belongs in secure coding and runtime assurance together: this is not only a patch-management issue. The named concept here is ORM translation risk, the gap between safe-looking application code and unsafe SQL generation. Practitioners should align code review, endpoint monitoring, and database privilege design around that gap rather than assuming the framework abstraction is inherently safe.
What this signals
ORM translation risk: security teams should now treat framework query builders as attack surface, not just developer convenience. If external parameters can shape the query tree, then application security controls have to start at the point where input becomes database logic.
Patch status and version numbers matter, but inventory discipline matters just as much. Frozen or inherited Django deployments can stay exposed long after the main platform has been upgraded, which means exposure management must include legacy branches, third-party-hosted services, and forgotten admin tools.
For practitioners
- Patch vulnerable Django branches immediately Upgrade to Django 5.2.8, 5.1.14, or 4.2.26 or later, and treat unsupported branches as high-priority replacement candidates.
- Map every exposed Django asset Build an inventory of internet-facing Django applications, including inherited, regional, and third-party-hosted services that may not appear in central records.
- Trace untrusted input into ORM query paths Review endpoints that accept nested filters, rich search objects, or JSON bodies and confirm they do not influence QuerySet.filter(), exclude(), get(), or Q() connector handling.
- Constrain database accounts to least privilege Use dedicated application database users with read and write rights limited to the minimum tables and operations required for each service.
- Monitor for anomalous query behaviour Alert on unexpected read volume, schema enumeration, and query shapes that do not match normal user search patterns, especially on public APIs.
Key takeaways
- CVE-2025-64459 shows that SQL injection can emerge from ORM query composition, not only from raw SQL strings.
- The highest-risk deployments are internet-facing Django applications that let user input shape search and filter logic.
- Patch the framework, inventory exposed services, and limit database privileges to reduce the blast radius of any successful injection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The flaw emerges in exposed request-to-query handling across API and filter paths. |
| Recommendation — Review API filter handlers for unsafe query construction and enforce strict request validation. | ||
| OWASP ASVS | V8 — Authorization | Unsafe query paths can bypass intended authorization logic at the application layer. |
| Recommendation — Verify that authorization checks still hold when requests reach dynamic query builders. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Database blast radius depends heavily on account scope after injection succeeds. |
| Recommendation — Apply least privilege to database accounts so injected queries cannot reach unnecessary data. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article stresses dedicated accounts and lifecycle control for vulnerable apps. |
| Recommendation — Use dedicated application accounts and remove broad shared credentials from Django services. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | SQL injection can be used to reach data and pivot through exposed application paths. |
| Recommendation — Map injection-driven database abuse to credential access and lateral movement detection logic. | ||
Key terms
- Django ORM: Django’s object-relational mapper translates Python query objects into database statements. It reduces the need for raw SQL, but it does not remove query risk when untrusted input can shape how those objects are assembled or combined.
- Query Tree: A query tree is the internal structure a framework uses to combine conditions before emitting SQL. If attacker-controlled values can influence that structure, the resulting statement may execute logic the developer never intended.
- SQL Injection: SQL injection is a flaw where untrusted input is interpreted as part of a database query. In practice, it lets an attacker read, change, or delete data by manipulating the application’s request handling rather than by logging in with valid credentials.
- Least Privilege Database Account: A least-privilege database account is a service credential limited to the minimum tables, operations, and schemas required for the application to function. It does not prevent injection, but it can sharply reduce what a successful exploit can read or change.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. The course helps security practitioners connect access, privilege, and lifecycle governance to the broader security programme.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org