What is CVE-2025-64459?
CVE-2025-64459 is a critical SQL injection vulnerability in the Django web framework’s ORM. It 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. Earlier, unsupported series such as 5.0.x, 4.1.x, and 3.2.x were not evaluated and may also be affected, which makes legacy deployments especially risky.
The issue sits in how Django builds database queries when QuerySet.filter(), QuerySet.exclude(), QuerySet.get(), and the Q() class handle a specially crafted dictionary. When that dictionary is expanded with ** and used as the _connector argument, an attacker can control how conditions are combined in the query tree and inject arbitrary SQL into the final statement.
The CVSS v3.1 assessment rates this as 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), which means remote, unauthenticated, low-complexity exploitation with high impact on data confidentiality and integrity. For any internet-facing Django application that accepts user-controlled filter parameters, CVE-2025-64459 should be treated as an urgent issue.
What assets are affected by CVE-2025-64459?
CVE-2025-64459 affects any deployment running vulnerable Django versions where user input can influence query construction in the ORM, especially through flexible filtering or search features.
On the external attack surface this usually includes:
- Customer, partner, or self-service portals built on Django that let users search, filter, or report on data.
- Public REST or GraphQL APIs that turn rich query parameters or JSON filters into QuerySet.filter() calls or complex Q() expressions.
- Admin or internal-style tools that ended up exposed to the internet through misconfiguration.
- Long-lived or “frozen” services pinned to older Django branches that were never upgraded.
These systems are especially attractive to attackers when they sit directly on the public internet, connect to databases with sensitive information such as customer records or credentials, and support complex filter patterns that are more likely to hit the vulnerable _connector handling. Given how common Django is across main products, side projects, regional brands, and third-party development, most organizations have more potentially exposed Django assets than their internal inventories suggest.
Are fixes available?
Yes. Django has released security updates that fix CVE-2025-64459 in all supported branches:
- Django 5.2: update to 5.2.8 or later
- Django 5.1: update to 5.1.14 or later
- Django 4.2: update to 4.2.26 or later
These releases add proper validation around the _connector keyword in Q and QuerySet internals so attacker-controlled dictionaries can no longer reshape the query tree in a way that leads to SQL injection.
Unsupported branches such as 5.0.x, 4.1.x, and 3.2.x were not evaluated in the advisory but may share the vulnerable logic. For applications on those versions, the safest option is to move to a supported, patched branch as quickly as possible.
Are there any other recommended actions to take?
Patching Django is the first step, but a few extra actions will help cut risk and make your response more effective.
- Map your Django exposure
Build a simple inventory of internet-facing domains and subdomains that appear to run Django, including assets in acquisitions, regional brands, and third-party hosting. Use framework fingerprints, common paths, and error pages to spot Django even when the stack is not obvious. - Review filter and search endpoints
Focus on endpoints that accept flexible filters or search structures such as JSON bodies, nested query parameters, or “advanced search” features. Trace how these values flow intoQuerySet.filter(),exclude(),get(), orQ(), especially where you expand dictionaries with**kwargs, since that pattern is central to CVE-2025-64459. - Tighten database permissions
Make sure each Django application uses a dedicated database account with least privilege. If an attacker manages to exploit the SQL injection, constrained permissions can significantly limit what they can read or modify. - Use WAF and monitoring as guardrails
A WAF tuned for SQL-like patterns cannot fully fix a framework-level bug, but it can block obvious payloads and flag probing. Combine this with monitoring for unusual query patterns, large unexpected reads, or schema enumeration in database logs.
Where legacy apps cannot be upgraded quickly, consider pulling them off the open internet or placing them behind VPN, strong authentication, and IP allow-lists until they can be modernized or decommissioned.
Is CVE-2025-64459 being actively exploited?
Right now, public data shows strong concern but no confirmed widespread exploitation.
Major databases treat CVE-2025-64459 as a critical SQL injection issue with a 9.1 CVSS score and clear remote, unauthenticated impact. Additional enrichment currently lists exploitation as “none” but marks the vulnerability as “automatable” with total technical impact, which means it is straightforward to script once an attacker decides to invest in it.
At the same time, detailed technical write ups, patch-diff analyses, and vendor advisories already walk through the root cause and exploitation path in plain language, and detection has started appearing in common vulnerability scanners. For a vulnerability this simple and this widespread, waiting for it to show up in a “known exploited” list before taking action is a bad idea. Internet-facing Django apps should be treated as high-priority for patching and review now.
How is CyCognito helping customers identify assets vulnerable to CVE-2025-64459?
CyCognito continuously discovers and analyzes externally exposed assets to help organizations understand whether CVE-2025-64459 may affect their environment. The platform identifies at-risk Django-based systems on the public internet, highlights exposure conditions that increase the likelihood of successful SQL injection (such as internet-facing applications that accept user-controlled filter parameters), and prioritizes remediation based on business importance and potential impact.
CyCognito has published an emerging threat advisory for CVE-2025-64459 within the CyCognito platform and is actively researching enhanced detection coverage for this vulnerability. The platform already surfaces exposed assets tied to the Django technology stack, and CyCognito advises customers to review any internet-facing systems running Django, especially those handling dynamic filters and search endpoints—to assess potential exposure, even if they are not yet explicitly identified as running one of the affected versions.
Check out CyCognito’s Emerging Threats page for more information on potentially relevant vulnerabilities.
How can CyCognito help your organization?
CyCognito gives security teams a clear view of every external asset, including systems they may not know exist. That visibility makes it easier to find Tomcat servers and understand which ones are vulnerable and exposed. Instead of working through large, noisy alert lists, teams see which systems matter most based on business impact and real-world exploit paths.
CyCognito then helps verify that the issue is fixed and continues watching for changes, so newly exposed systems don’t slip by. This helps organizations move faster, cut risk confidently, and stay ahead of attackers instead of responding after the fact.
To learn how CyCognito can help you understand your external attack surface and exposed risks, please visit our Contact Us page to schedule a demo.
